Re: Using terminal output as input
>>just figured that this would be common enough to be a part of the
>>shell itself,
>
> Probably mostly for historical reasons, the shell doesn't handle terminal
> manipulations. In particular, the shell doesn't know that the input you
> want is 5 rows up and 12 columns over or have any (special) support for
> moving the cursor to allow you to select something like that.
>
> There are a lot of different terminals. Some don't even mix your input with
> the shell (or other process's) output. A good shell works equally well with
> any of them.
>
I see, thanks.
>>not something that would require workarounds or hacks.
>
> Additional tools are not "workarounds" or "hacks". They are separations of
> duties/roles which allows a more flexible and robust environment.
>
Correct, tools such as screen are not a hack. But this (suggested earlier) is:
$(ekiga 2>/dev/stdout | head -2 | tail -1)
> Unix and Linux come from a culture were providing lots of generalized small
> tools to the user was found to be more flexible than the alternatives,
> because it allowed individual users and communities to build very
> specialized tools without starting entirely from scratch.
>
> It's not a problem that cat/sed/grep doesn't know how to convert your MS
> Word Document to text, it isn't the role of that tool. It's not a problem
> that LVM doesn't resize the filesystem before/after resizing the LV, it
> isn't the role of that tool. It's not a problem that your shell doesn't
> have copy-and-paste, it isn't the role of that tool.
>
While in general I agree, I would assume that handling user input /
output is the role of the terminal (not the shell), and therefore
copy/paste falls into it's role.
> Now, it may be that you need higher level tools. That's fine, but don't
> complain that a spool of copper wire is not a jackhammer.
>
Not once did I complain! I asked how to do what I need, but I did not
complain that it is not done how I would prefer.
>> I intend to learn screen.
>
> AIUI, screen is quite scriptable and should be capable of sending output to
> the process(es) attached to it. This would allow you to write "screen
> scripts" that used the shell for what it is good at and used screen for what
> it is good at.
Thanks, Boyd.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
Reply to: