Re: Bash does not read up the whole script which it is currently executing
John Reiser a écrit : > On 08/04/2009 12:48 AM, fam...@icdsoft.com wrote: >> First I would like to say that I'm not sure if this is a bug or a >> feature of Bash. >> If it is a feature, please let me know how to turn it off; or better >> make it disabled by default... >> >> The problem is that Bash does not read up the whole script which it is >> currently executing. >> As a result of this, if we update the script file with a newer version >> while it is running, this may lead to unpredicted results. > > It is an intended design feature that the shell reads only as much as > necessary > to proceed at the moment. This is required so that subprocesses can share > the same > stdin as the shell. Bytes for input to the shell alternate with bytes for > input > to each subprocess that does not have redirection (or closure) specified for > its stdin. I am not sure I get this... first of all, the script itself is usually not read from stdin (but from fd 255 in bash). Now considering the seldom cases where the script is actually read from stdin, are you saying that: it is a wanted feature that subprocesses can concurrently slurp and steal the code executed by their parent? Wow, that sounds really weird and not something I would wish, but rather a design limitation that I should constantly worry about. Regards, Marc
Re: Why are curly braces different than parens for cmd grouping?
Chet Ramey wrote:
> Linda Walsh wrote:
> > A previous note had me wondering why the syntax for using
> > curly braces to group expressions wasn't able to be the same as
> > using 'paren's.
>
> Braces are reserved words. Parentheses are operators. Blame
> Steve Bourne.
I wonder about the motivation, or was it just an "oversight"?
Some tried to adjust this,
- You did so in bash-1 (just found out by coincidence),
although blanks were required, "{ cmd }".
- D.Ritchie made them operators in the svr2-derived V8 shell,
where "{cmd}" works.
- and the SUS rationale to the command language explains that
this step was delayed for portability reasons but left it open,
"It is possible that a future version of the Shell [...]"
On the fly COLORING and UNDERLINING (a la FISH)
Dear Bash developers, We are long-time users of Bash. A few years ago we encountered an alternative Linux shell called Fish (www.fisshell.org). For us this shell has some compelling features that we would love to avail of in Bash: 1."On the fly COLORING": If you type the name of a binary - or a command - you can immediately see if that binary - or command - exists, because if it exists it would be shown in green on the command-line. If the binary does not exist it will be shown in red, so that you know that the binary/command is not available. This may indicate to you that you made a typo. Fish also colors syntactic constructs on the fly. The same applies to mismatched parentheses and quotes. 2."On the fly UNDERLINING": If you start typing the name of a file - or a command - you can immediately see if the pattern you typed so far coincides with an actual file - or command - on your system. If a file matching the pattern exists, it will be underlined. If a file matching the pattern does not exist, what you type will not be underlined. The main reason why we do not want to keep using Fish is that Fish provides its own scripting language, which is incompatible with Bash syntax. So we would be very happy if the requested features could be implemented in Bash. We also think that these two features may be useful to many other Bash users. Therefore, we would like to ask how difficult it is to implement them in Bash, and if the Bash developers would be interested in putting them on Bash's wish list. Best wishes, Guido van Steen, Isaac Dupree and Benny Cherniavsky P.S. Installing Fish under Debian/Ubuntu just takes "sudo apt-get install fish". It is also available for Fedora through "yum install fish". For those interested in a VMware image with Fish installed, we can upload an Debian image to you of about 100MB with Fish installed as the main shell.
Re: possible bug with $@ and and non-standard IFS
> If you use nd="${dh}$*" before resetting IFS, you'll get the output you
> in bash-3.0 through bash-4.0.
But I don't in Bourne shell, I get smith0.0. So neither construct
works in a portable manner. :(
JR
