Re: variable assignments and parameter expansion in a single command
On Sat, 24 Mar 2007 19:32:35 -0400 Chet Ramey <[EMAIL PROTECTED]> wrote: > Kevin F. Quinn wrote: > > my interpretation of > > "variable assignment" is the `A=' part of the statement; i.e. that > > the rhs of the assignment is expanded. > > It's not; the entire word, including the portion after the `=', is a > variable assignment. ah; that explains the bash behaviour w.r.t. Posix. I concur, as: $ A= one is two words due to the whitespace, so the rhs must be part of the word. > None of these shells are or claim posix compliance. The Solaris posix > shell is /usr/xpg4/bin/sh (or something). Of the others, dash is > closest to Posix compliance. FWIW I tried also /usr/xpg4/bin/sh (with the Belenix livecd, SunOS 5.11) and that shows the same as sh/ash/dash/bb. > I don't get these results with bash-3.2. I get "one two" for B both > times with bash (and ksh93, incidentally). Sorry; should have said - that was with bash-3.1.17; I should have tried 3.2. I see the same as you with bash-3.2 (and ksh-93s). Thanks again for your patience :) -- Kevin F. Quinn signature.asc Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Syntax question
thx for the answer. I didn't realize my error, that white space defines the separation of words, even when dealing with symbols. wish vim syntax highlighted this stuff as the shell interprets because it sees it as a comment. anyways like I said thanks for the explanation. I'm not going to forget this lesson anytime soon. On 3/25/07, Paul Jarc <[EMAIL PROTECTED]> wrote: "Caleb Cushing" <[EMAIL PROTECTED]> wrote: > the line > FEATURES="parallel-fetch ccache distlocks"# userfetch userpriv usersandbox > > I was told my bug is not a bug because there was no space in between the "# > > putting a space does fix the problem but I can't recall that I've ever seen > any documentation saying that mid line comments need a space before the # man bash, in the section COMMENTS: a word beginning with # causes that word and all remaining characters on that line to be ignored In your case, the # is not at the beginning of a word, so it doesn't start a comment. (Quotes don't separate words; a word can be partly quoted and partly not.) paul -- Caleb Cushing ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash is executing command at the prompt when closing
[EMAIL PROTECTED] wrote: > Bash Version: 3.1 > Patch Level: 17 > Release Status: release > > Description: >Please see mandriva bugreport for a more detailed explanation >with examples at: http://qa.mandriva.com/show_bug.cgi?id=21708 > >The problem is that bash always executes the command at the prompt >when closing the terminal window. > > Repeat-By: >Open up a terminal emulator, >(i use konsole for that, but it works also with rxvt) >use "su" to get root. Enter a command, which is normally >only available to root (i used rpmdrake for that) >DO NOT press enter, but quit the terminal by clicking >on the exit button. >The command which was at the prompt will be executed. This is not an error -- readline and the shell read EOF when this happens, not an error from read. Readline returns the line to the application, without executing any function bound to accept-line. >Alternative method: > >create a text file with a command, but NO return at the end. > >echo -n ls > testfile >chmod 700 testfile >./testfile > you'll find your command has been executed. EOF delimits a token; it is not an error condition. If the delimited token is sufficient to complete a command, the command is considered parsed and subsequently executed. All shells I looked at behave this way. 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/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash 3.2 breaks firehol
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux notebook 2.6.20.3-ubuntu1wr1 #3 SMP PREEMPT Sun Mar 25 19:17:56 CEST 2007 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: XX Release Status: release Description: I dont know the patch level because I downgraded to 3.1 patchlevel 17 which works. I dont want to reinstall 3.2 again because that would annihilate my firewall. For details, please see http://sourceforge.net/tracker/index.php?func=detail&aid=1607442&group_id=58425&atid=487692 Fix: Downgrade to 3.1 pl 17 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash 3.2 breaks firehol
[EMAIL PROTECTED] wrote: > Machine Type: i486-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: XX > Release Status: release > > Description: > I dont know the patch level because I downgraded to 3.1 patchlevel 17 > which works. I dont > want to reinstall 3.2 again because that would annihilate my firewall. > For details, please see > > http://sourceforge.net/tracker/index.php?func=detail&aid=1607442&group_id=58425&atid=487692 > I took at look at the bug report on sourceforge. I'm not sure I understand it. From what I gather, the original poster seems to expect these two statements to display identical output: printf " %q\n" a b c "d e f g" printf " %b\n" a b c "d e f g" I'm not sure why, since the two conversions are defined to do very different things. Bash-3.1.17 behaves the same as bash-3.2.15 here. There are differences in behavior between bash-3.1.17 and bash-3.2. One of them may be causing problems with firehol. This isn't it, though. I think it might be the fact that bash-3.2 fixed a bug in bash-3.1 that caused it to not quote null arguments given to the %q conversion specifier, but I can't really be sure. 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/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
