Re: Select menu list formatting
wellsj35 wrote: Hi All, I have noticed that any number larger than 10 items in my select menu list will wrap the menu. I am not sure if this is a terminal issue or it is the way the BASH select function works It's the way the bash select command works. If you'd like the menu printed one item per line, you're going to have to modify the source. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: FAQ E4
Maximillian Murphy wrote: E4) If I pipe the output of a command into `read variable', why doesn't the output show up in $variable when the read command finishes? Would it cause a great deal of upset if the last section of a pipeline ran in the current process? It could work when job control is not active -- nobody has done the work -- but is fundamentally incompatible with job control and process groups. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: FAQ E4
Am 26 Apr 2008 um 21:49 schrieb Chet Ramey:
Maximillian Murphy wrote:
E4) If I pipe the output of a command into `read variable', why
doesn't
the output show up in $variable when the read command finishes?
Would it cause a great deal of upset if the last section of a
pipeline ran in the current process?
It could work when job control is not active -- nobody has done the
work -- but is fundamentally incompatible with job control and
process groups.
Chet
Is the problem one of catching signals? So if (and it's a big if) I
can find a way of handling control-z, control-c etc and getting the
expected reaction then I'd get the go-ahead?
A solution would be to consider forking on catching a signal so that
if a pipeline is say sent to the background one half can background
and the other return to the user.
My current feeling - having hardly looked at the code - is that this
should be feasible. Are there any other problems to consider before
dedicating serious time to this?
An alternative would be to go straight for a general primitive and
find a way of allowing each section of a pipeline to set values in
the original shell. Each section could return a string that would be
evaluated in the main shell:
echo humpty dumpty | wc | { read lines words chars ; tellparent
"lines=$lines ; words=$words ; chars=$chars" ; }
which would have the same effect as:
eval $(echo humpty dumpty | wc | { read lines words chars ; echo
"lines=$lines ; words=$words ; chars=$chars" ; })
except that it wouldn't use stdout as its communication channel.
Why take half measures?
I believe ksh's method is to try to guess whether the parent shell
wants to run the last section of the pipe. I've had cases where it's
guessed wrong so I'd rather let the programmer dictate what is to be
kept and what to be dumped. At the moment I favour the second of the
above. It's the most general solution.
Regards, Max
