>>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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
