Bugzilla – Bug 151000
different shell behavior when using single quotes
Last modified: 2006-03-08 10:34:08 UTC
Kernel: 2.6.16-rc1-git3-7-xen I discovered this problem while installing Oracle 10.2: The installer hangs at the position of Linking ntcontab *** this is NOT a Oracle problem, you can reproduce it without Oracle ***** The problem occurs with the script 10.2.0/bin/gennttab. Here the extract of the file to reproduce: -------------------------------- NM=/usr/bin/nm SED=/bin/sed AWK=/usr/bin/awk GREP=/bin/grep EXPR=/usr/bin/expr LN=/bin/ln ECHO=/bin/echo TRANSPORTS="US TCP BEQ TCPS DCE NMP RAW SDP" TtoINI="US:ntusini TCP:nttini BEQ:ntpini TCPS:ntzini DCE:ntodrini NMP:ntnini RAW:ntrini SDP:nttsdpini" TtoBAS="US:ntus TCP:ntt BEQ:ntp TCPS:ntz DCE:ntodr NMP:ntn RAW:ntr SDP:ntt" TtoNAM="US:IPC TCP:TCP/IP BEQ:BEQueath TCPS:SSL DCE:DCE NMP:NamedPipes RAW:RAW SDP:SDP" for T in $TRANSPORTS; do ### the line-break is from the script, it's not a problem of copy/paste LIB=`$ECHO ${TtoLIB} | $SED 's/ /\\ /g' | $GREP "^${T}:" | $AWK -F: '{print $2}'` INI=`$ECHO ${TtoINI} | $SED 's/ /\\ /g' | $GREP "^${T}:" | $AWK -F: '{print $2}'` BAS=`$ECHO ${TtoBAS} | $SED 's/ /\\ /g' | $GREP "^${T}:" | $AWK -F: '{print $2}'` done ------------------------------------------ With Suse9.3, it works With Suse10.1, you get the following error messages: /bin/sed: -e expression #1, char 7: unterminated `s' command It seems that it is a different behavior of the shell, and not a different behavior of sed (I also tried the sed version from 9.3) PS: the Oracle installer hangs because $LIB, $INI, $BAS are empty and "grep $LIB /tmp/xxx" becomes to "grep /tmp/xxx" --> endless waiting
The position of the line break looks a bit unhappy to me... Werner: Should this work that way? It's an script from the Oracle installer and probably we should make this work to avoid lots of confusion - if it does not break anything.
The problem is the doubled backslash. IMHO this should be simply one backslash. The new bash does not accept such bugs anymore.
it is not only bash related. I discovered the following effects: suse93 bash: OK suse93 pdksh: OK suse101 bash NOT OK suse101 with bash from suse93: OK suse101 with pdksh from suse93: NOT OK (but how can this be bash-related?) You can say, Oracle is not certified for opensuse10.x, but how you will certify Suse Enterprise 10 (or 11?) for Oracle when the Oracle-installer does not work?
The bash script of Oracle is broken. What do you expect? Should I break the bash 3.1? You may discuss this on the bash mailing lists.
No, I didn't say that. And I didn't say the Oracle code is good (but it worked until now) What I say is, that with an old release of bash it works (that is not a solution, that is a workaround) BUT: the problem is not bash related. As I said, it works with pdksh on Suse9.3 and it DOES NOT work with the SAME pdksh-binary in Suse10.1. (so why should I discuss a pdksh problem on a bash mailing list...) What should I tell my Oracle customers? Suse does no longer support Oracle. Buy RedHat Enterprise instead of Suse Enterprise in the future? (I know, that's bugzilla of OpenSuse, but SLES will be based on it...) A more constructive proposal: Introduce a compatibility parameter (something like LD_ASSUME_KERNEL) I leave the bug unchanged as "resolved invalid". When you really think it is not a problem for Suse to break Oracle compatibiliby, leave it as is, otherwise you can reopen it.
Hmm ... redhat will have the same problem with the new bash. Btw: Do you've tried out the original ksh? AFAIS this one works and with the pdksh I've also no problems. Both the ksh and the pdksh I used for testing are definitly build for openSuSE 10.1.
OK, I've fix for that. Submited for the next version of SL 10.1. Also submited to bug-bash@gnu.org.
*** Bug 155870 has been marked as a duplicate of this bug. ***