Arithmetic expressions and parameters with newlines breaks
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 mainserver 2.6.18-4-486 #1 Wed May 9 22:23:40 UTC 2007 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: Parameters inside arithmetic contexts like $(()) and (()) break the expression parsing when they contain a newline Repeat-By: $ foo="12 > 34" $ echo $((foo)) bash: 12 34: syntax error in expression (error token is "34") $ ((foo)) bash: ((: 12 34: syntax error in expression (error token is "34") Fix: ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Arithmetic expressions and parameters with newlines breaks
Jan Schampera wrote: > Parameters inside arithmetic contexts like $(()) and (()) break > the expression parsing when they contain a newline Thank you for your bug report. > $ foo="12 > > 34" > > $ echo $((foo)) > bash: 12 > 34: syntax error in expression (error token is "34") > > $ ((foo)) > bash: ((: 12 > 34: syntax error in expression (error token is "34") That seems like a valid syntax error to me. The newline is not special. This would be the same as any whitespace. $ foo="12 34" $ echo $((foo)) bash: 12 34: syntax error in expression (error token is "34") What behavior did you expect to see when the evaluated expression contained whitespace? What would you expect from "12 34"? It is not a number. It is two numbers. There is no operator between them such as "12 + 34" or other. What other result than a syntax error is possible here? Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Arithmetic expressions and parameters with newlines breaks
Jan Schampera <[EMAIL PROTECTED]> writes: > Description: > Parameters inside arithmetic contexts like $(()) and (()) break > the expression parsing when they contain a newline > > Repeat-By: > $ foo="12 > > 34" > > $ echo $((foo)) > bash: 12 > 34: syntax error in expression (error token is "34") Why do you think this is a bug? Two numbers separated by whitespace cannot form a valid expression. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Fw: Arithmetic expressions and parameters with newlines breaks
Begin forwarded message: Date: Mon, 2 Jul 2007 18:32:49 +0200 From: Jan Schampera <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (Bob Proulx) Subject: Re: Arithmetic expressions and parameters with newlines breaks On Mon, 2 Jul 2007 10:08:08 -0600 [EMAIL PROTECTED] (Bob Proulx) wrote: > What behavior did you expect to see when the evaluated expression > contained whitespace? What would you expect from "12 34"? It is not > a number. It is two numbers. There is no operator between them such > as "12 + 34" or other. > > What other result than a syntax error is possible here? Hi Bob, thanks for your reply! Well, I guess intuitively expected that it evaluates to 0, like for example: $ test=string $ echo $((test)) 0 But I just made some experiments (which I should have done before) and read the manual again a bit closer: In this example I really reference the variable "string" (as designated operand) which is unset/null and thus evaluates to 0. I also saw this can be done in any depth. So, excuse my wrong interpretion of the manual (maybe that needs to be marked extra by a sentence or a half in manual). It's definitely not a bug (it is - between screen and chair!). Best regards and thanks again for quick reply, Jan ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash: no job control in this shell
[EMAIL PROTECTED] wrote:
> Hi Bob, a quick question if I could as I am trying to determine if my bash
> thinks it has a tty device or not and therefore is interactive or not.
Internally bash will use the libc isatty(3) routine to determine if
the input/output files are tty devices. In the shell these are
available in the 'test' operator as the '-t' file operator.
$ test -t 0 && echo input is a tty
$ test -t 1 && echo output is a tty
> I do use openpty to get a master/slave and associate the slave FD with the
> bash. I *think* my bash is interactive, because right after the "no job
> control" I get a bash prompt ([EMAIL PROTECTED]:/homelocation>).
The technique I have used is to look at $-, the option flags, and see
if 'i' is present there.
PS1 is set and $- includes I if bash is interactive, allowing a
shell script or a startup file to test this state.
Something like this works:
case $- in
*i*) echo shell is interactive ;;
esac
Other people prefer to use a test for PS1 such as this example.
test "${PS1+set}" = set && echo shell is interactive
Chet Ramey followed up with this information:
> > In general, this happens when bash thinks it's interactive but can't
> > obtain a handle to the controlling terminal that allows it to
> > manipulate the controlling terminal's process group. Since that's all
> > job control really is -- switching the terminal's process group
> > between processes -- bash turns off job control if it's not available.
> So it seems like it is interactive in that I am getting prompts, the only
> things I have seen not work are using less as an editor, and more recently
> noticed Ctrl-C (sent as a hex '03' to bash) does not seem to interrupt
> things.
It would be useful to see what 'stty -a' reports. That will dump the
current tty settings, if it is a tty. I will simulate not being on a
tty by redirecting from /dev/null.
$ stty -a ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
> I was trying to find out what the default terminal parameters and window
> size are for openpty() as I am currently sending in NULLs for those. I
> tried sending in window size parameters of 24x80, 640x480pix but that
> didn't seem to make a difference to my "less" problem.
I am not familiar with openpty(). Perhaps someone else on the mailing
list will have information about that operation.
> So again, curious if it sounds like my bash shell is interactive. If it
> sounds so, then would appreciate any leads on how i might better find out
> why it is printing out the "no job control", so that maybe if I can rectify
> that, it might also rectify the "less" editing problem .. thanks ...
Sorry but I don't have any hints for you there. Personally I would
need to learn how setting up ptys is typically done these days, such
as by inspecting how 'xterm' or 'expect' or other such programs do
this. As I recall Marc Rochkind discusses this operation in detail in
his book "Advanced UNIX Programming" and therefore might be a good
reference. A lot of best practices have changed since the last time I
set up a master-slave pty pair and I only remember the old ways.
Bob
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Arithmetic expressions and parameters with newlines breaks
Jan Schampera wrote: > Well, I guess intuitively expected that it evaluates to 0, like for > example: > > $ test=string > $ echo $((test)) > 0 In that case it is like the 'atoi(3)' routine. A non-numeric has no number value and is evaluated to be zero. A single zero is a valid arithmetic expression. $ echo $((0)) 0 But two numbers is a different case. $ echo $((0 0)) sh: line 1: 0 0: syntax error in expression (error token is "0") This is the same in bash as in other languages too. They are all very similar on this point. > But I just made some experiments (which I should have done before) and > read the manual again a bit closer: In this example I really reference > the variable "string" (as designated operand) which is unset/null and > thus evaluates to 0. > > I also saw this can be done in any depth. Yes. Well, all's well that ends well. :-) > So, excuse my wrong interpretion of the manual (maybe that needs to be > marked extra by a sentence or a half in manual). It's definitely not a > bug (it is - between screen and chair!). Suggestions for improvements to the documentation are always appreciated. > Best regards and thanks again for quick reply, Good luck! Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
