Re: [Fwd: Re: bash 3.1.10 breaks configure scripts (was Re: configure scripts ignores parameters)]
Mike Jakubik wrote: > FYI. This has been a known issue with bison-1.75 for over three years: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167635;archive=yes http://lists.gnu.org/archive/html/bug-bash/2003-01/msg00061.html http://lists.gnu.org/archive/html/bug-bash/2004-09/msg00118.html Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: quoting inside backquotes in 3.1
> Is it intentional that the following script, which worked in 2.05b now > produces errors in 3.1: > > : `: "\\""` > > That now results in: unexpected EOF while looking for matching ``' > Using a third backslash fixes it but this is inconsistent with ash bash2 > bsh ksh pdksh and zsh. No, it is not intentional, and yes, it is a bug. Official patch 10 (even the updated version) and patch 11 do not help here - maybe Chet can come up with patch 12? It is a little more obvious what is going on if you use echo instead of : (that is, echo `echo "\\""`). The backtick should parse the first backslash as quoting the second, so that the command passed to the command substitution is now (echo "\""). Then the outer echo reprints the result, for an overall output of " in a compliant shell. bash-3.1 is indeed misparsing this construct. > > Oliver > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. Too late - it is now publicly archived. Please don't use unenforceable legalese trash like this in your emails to public mailing lists - if necessary, open up a second web-based email account rather than sending from an account that includes such a disclaimer. -- Eric Blake ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: quoting inside backquotes in 3.1
Oliver Kiddle wrote: > Is it intentional that the following script, which worked in 2.05b now > produces errors in 3.1: > > : `: "\\""` > > That now results in: unexpected EOF while looking for matching ``' > Using a third backslash fixes it but this is inconsistent with ash bash2 > bsh ksh pdksh and zsh. This is how I interpreted POSIX's requirement that quoted strings inside backquotes be recursively processed: "While processing the characters, if instances of expansions or quoting are found nested within the substitution, the shell shall recursively process them in the manner specified for the construct that is found." The double-quoted string is processed, the backslash quotes the succeeding backslash, the second double quote terminates the quoted string, and we are left with a syntax error. This POSIX requirement may be new -- I didn't analyze previous shell implementations -- but its intent seems to be to allow embedded quoted strings to contain backquotes (for instance). I will see if I can find a way to preserve backwards compatibility. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: trap handler scope wrong?
Phillip Susi wrote:
> Chet Ramey wrote:
>>> trap "cat $LOG > &3" ERR
>>> {
>>> foo
>>> bar
>>> } 3>&1 > /dev/null
>>
>> That's about right, but you need >&3 in the trap command.
>
> I did have > &3 in the trap command, see?
There can't be a space between `>' and `&'. That's a syntax error.
> I'm a bit worried though about hard coding the fd 3. Is there a way to
> get the next available fd number and save it in a variable, rather than
> hard code 3?
Why worry about it? The script writer is entitled to use any file
descriptor between 0 and 9. If bash is using it internally, it will
switch to another.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live Strong. No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to suppress async messages for background jobs
Paul Jarc ha scritto: Francesco Montorsi <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED]:~$ kwrite & =>[1] 20986 [EMAIL PROTECTED]:~$ =>[1]+ Donekwrite [EMAIL PROTECTED]:~$ is there a way to tell bash not to print those lines marked with => ? If you don't need to refer to the process as %1, etc.: $ ( kwrite & ) I have this in my .bashrc to I can use alt-Enter to run something in the background without keeping track of it as a shell job: bind $'Meta-RET: "\001(\005&)\r"' Thanks a lot !!! This is exactly what I was searching for; however for some reason copying it verbatim to my .bashrc did not work so I've slightly changed as: bind '"\x1b\x4f\x4d"':"\"\001(\005 &)\r\"" so that shift+enter now does the trick ;) Thanks, Francesco ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: trap handler scope wrong?
Phillip Susi wrote:
> Does redirecting to /dev/tty work if the original stdout of the shell
> was NOT a tty? This script runs as a cron job so it has no tty.
Probably won't work to use /dev/tty in that case.
> Also is there a better way to save the original stdout and switch back
> to it than this:
>
> trap "cat $LOG > &3" ERR
> {
> foo
> bar
> } 3>&1 > /dev/null
That's about right, but you need >&3 in the trap command.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live Strong. No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: LINES and COLUMNS variables are not exported
Thierry EXCOFFIER wrote: > LINES and COLUMNS variables are not exported, > so applications using these variables can not > find the screen size. The LINES and COLUMNS variables are an *override* to applications. It is not an application's primary method of getting the size of the screen. Therefore they should not be exported by default. These should only be exported when the user wants to force a specific behavior. (e.g. COLUMNS=200 dpkg -l) Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: trap handler scope wrong?
Chet Ramey wrote:
trap "cat $LOG > &3" ERR
{
foo
bar
} 3>&1 > /dev/null
That's about right, but you need >&3 in the trap command.
I did have > &3 in the trap command, see?
I'm a bit worried though about hard coding the fd 3. Is there a way to get the
next available fd number and save it in a variable, rather than hard code 3?
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Fwd: Re: bash 3.1.10 breaks configure scripts (was Re: configure scripts ignores parameters)]
Nicolas Rachinsky wrote: > * Chet Ramey <[EMAIL PROTECTED]> [2006-03-05 12:38 -0500]: >> This has been a known issue with bison-1.75 for over three years: >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167635;archive=yes >> http://lists.gnu.org/archive/html/bug-bash/2003-01/msg00061.html >> http://lists.gnu.org/archive/html/bug-bash/2004-09/msg00118.html > > If it's a known issue, why does the configure script select the > bison-1.75 instead of the working yacc? All things being equal, bash prefers bison. Yacc has its own issues, especially in the area of reentrant parsers (calling yyparse() recursively, for instance). All programs have bugs, and yacc has had its share. > If this can't be changed easily, perhaps you can add a note in INSTALL > or somewhere else, warning people to use bison-1.75. Good idea. This is good material for NOTES. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: trap handler scope wrong?
Phillip Susi <[EMAIL PROTECTED]> wrote: > Chet Ramey wrote: >> That's about right, but you need >&3 in the trap command. > > I did have > &3 in the trap command, see? You have "> &3". You need ">&3", without a space. > I'm a bit worried though about hard coding the fd 3. Is there a way > to get the next available fd number and save it in a variable, > rather than hard code 3? Unfortunately, no. You could use a higher number, which would be less likely to be used, but if you want to be portable to other shells, you can only go up to 9. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to suppress async messages for background jobs
Francesco Montorsi <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED]:~$ kwrite & > =>[1] 20986 > [EMAIL PROTECTED]:~$ > =>[1]+ Donekwrite > [EMAIL PROTECTED]:~$ > > is there a way to tell bash not to print those lines marked with => ? If you don't need to refer to the process as %1, etc.: $ ( kwrite & ) I have this in my .bashrc to I can use alt-Enter to run something in the background without keeping track of it as a shell job: bind $'Meta-RET: "\001(\005&)\r"' paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: quoting inside backquotes in 3.1
> This is how I interpreted POSIX's requirement that quoted strings > inside backquotes be recursively processed: My interpretation differs from yours, in order to match traditional behavior. > > "While processing the characters, if instances of expansions or quoting > are found nested within the substitution, the shell shall recursively > process them in the manner specified for the construct that is found." I take this to mean that the entire backtick word is parsed recursively according to the rules specified for backticks, which are listed later on as: "Within the backquoted style of command substitution, backslash shall retain its literal meaning, except when followed by: '$', '`', or '\' (dollar sign, backquote, backslash). The search for the matching backquote shall be satisfied by the first backquote found without a preceding backslash; during this search, if a non-escaped backquote is encountered within a shell comment, a here-document, an embedded command substitution of the $( command) form, or a quoted string, undefined results occur. A single-quoted or double-quoted string that begins, but does not end, within the "`...`" sequence produces undefined results." I take this to mean that all " encountered inside the `` are preserved literally as the basis of input to the command-substitution subshell, without regards to recursive double-quoted string parsing (unlike $() command substitution). After the end of the `` is found, then only the \ preceding \, `, or $ are stripped, and all remaining characters are fed to the subshell performing the command substitution. It is at that point, in the subshell, where double-quoted strings must be properly terminated for predictable results (although some older shells supplied the missing closing quote rather than causing a syntax error). In the sample that started this thread, the subshell sees three double quotes, but the middle one is preceeded by a backslash, which forms a valid double quoted string. > > The double-quoted string is processed, the backslash quotes the > succeeding backslash, the second double quote terminates the quoted > string, and we are left with a syntax error. I disagree that this is a syntax error. Double-quoted strings are not parsed recursively inside ``, rather, the double quotes are collected literally as characters into the subscript. Double-quoted strings are only parsed recursively inside $() command substitution, which requires a valid shell script (which is one of the reasons that $() is so much nicer than ``). > > This POSIX requirement may be new -- I didn't analyze previous shell > implementations -- but its intent seems to be to allow embedded quoted > strings to contain backquotes (for instance). To have a \ inside of ``, you quote the backslash with an additional backslash. The only construct recursively parsed inside of `` when searching for the terminating ` are the constructs \\, \`, and \$. > > I will see if I can find a way to preserve backwards compatibility. > -- Eric Blake ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
