bash script in background gets interrupted if carriage return is hit...
Hi, I have a script that when run in background and while it's running hitting a carriage return causes it's to completely stop the script and the terminal in which it's running disappears. It seems as though it received a interrupt signal. Is there some kind of a job control or terminal keys getting mis-represented. Regards, Ken
RE: bash script in background gets interrupted if carriage return is hit...
Hi Chet, I was able to solve the problem. By uncommenting a line in our script that was setting a "set -m" for Solaris platform I was able to resolve this issue. Thanks to everyone for looking into this one and advising. Regards, Ken -Original Message- From: Chet Ramey [mailto:[EMAIL PROTECTED] Sent: Friday, October 12, 2007 5:07 PM To: Ken Failbus Cc: bug-bash@gnu.org; [EMAIL PROTECTED] Subject: Re: bash script in background gets interrupted if carriage return is hit... Ken Failbus wrote: > I have a script that when run in background and while it's running > hitting a carriage return causes it's to completely stop the script and > the terminal in which it's running disappears. It seems as though it > received a interrupt signal. Is there some kind of a job control or > terminal keys getting mis-represented. Look at the output of `stty -a'. 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/
bash -n doesn't seem to catch all syntax errors...
Hi Guys, When I specify on command-line "bash -n ". Bash doesn't check for valid syntax errors. E.g. if variable is missing a "$" infront of it while assigning a value. This is not catched by bash. Is there a more specific option that should be specified to bash to check for syntax errors. Regards, Ken ### example code p=hello e=world If [ p != $e ];then echo "not equal" else echo "equals" fi
RE: bash -n doesn't seem to catch all syntax errors...
Hi Guys, I understand that the example I provided is valid, use to writing scripts in correct format. Your explanations are convincing. But I need to provide a better example that what it means that would help you to understand as to where I saw the issue or call it my ignorance of providing with a good bad example. That way I would be heading in the right direction. Ken -Original Message- From: Stephane Chazelas [mailto:[EMAIL PROTECTED] Sent: Tue 10/16/2007 3:08 AM To: Ken Failbus Cc: bug-bash@gnu.org Subject: Re: bash -n doesn't seem to catch all syntax errors... On Mon, Oct 15, 2007 at 06:27:43PM -0400, Ken Failbus wrote: > Hi Guys, > > When I specify on command-line "bash -n ". Bash doesn't > check for valid syntax errors. E.g. if variable is missing a "$" infront > of it while assigning a value. This is not catched by bash. Is there a > more specific option that should be specified to bash to check for > syntax errors. > > Regards, > Ken > > ### example code > p=hello > e=world > If [ p != $e ];then > echo "not equal" > else > echo "equals" > fi [...] The error in your code is that you left $e unquoted. In list context (as in the arguments of a simple command like "["), an unquoted variable is treated as list of file patterns, not a litteral string. [ p != "$e" ] as you want to check if the value of $e is "p". Another error is the "then" without a "if" (you spelled it "If"). Note that "[" is a simple command that is not considered any different by bash from "echo" for instance. So, if echo p != $e ] is valid syntax, so is [ p != $e ] Of course you don't need to quote string litterals as in some other languages, as otherwise you'd need to write: "echo" "p" "!=" $e (remember that "echo", "p"... are all only arguments to the echo command, none is treated differently from the other as far as the shell is concerned) The usage of quotes can be very confusing in most Bourne like shells as it's completely different (almost the opposite) from other languages. In shell, you generally need to put quotes around variables, and generally don't need to put them around litterals. Quotes really fit a different purpose from in other languages. It's not for "typing", it's to prevent some special behaviors (like expansions or splitting). I'd suggest you read some litterature about shell syntax and quoting in particular. -- Stéphane
RE: bash -n doesn't seem to catch all syntax errors...
Hi Guys, I got the correct bad example of how bash doesn't perform correct syntax checking. Following example below show that inclusion of "shopt -s extglob" should take care of the extended pattern matching features e.g. +([0-9]). bash -x /tmp/mydummy + shopt -s extglob + rm -f '/tmp/file.+([0-9])' + exit 0 But if "bash -n" is run it doesn't understands +([0-9}) bash -n /tmp/mydummy /tmp/mydummy: line 3: syntax error near unexpected token `/tmp/file.+([' /tmp/mydummy: line 3: `rm -f /tmp/file.+([0-9])' Can you provide insight into this. Thanks & Regards, Ken -Original Message- From: Ken Failbus Sent: Tuesday, October 16, 2007 6:47 AM To: Stephane Chazelas Cc: bug-bash@gnu.org Subject: RE: bash -n doesn't seem to catch all syntax errors... Hi Guys, I understand that the example I provided is valid, use to writing scripts in correct format. Your explanations are convincing. But I need to provide a better example that what it means that would help you to understand as to where I saw the issue or call it my ignorance of providing with a good bad example. That way I would be heading in the right direction. Ken -Original Message- From: Stephane Chazelas [mailto:[EMAIL PROTECTED] Sent: Tue 10/16/2007 3:08 AM To: Ken Failbus Cc: bug-bash@gnu.org Subject: Re: bash -n doesn't seem to catch all syntax errors... On Mon, Oct 15, 2007 at 06:27:43PM -0400, Ken Failbus wrote: > Hi Guys, > > When I specify on command-line "bash -n ". Bash doesn't > check for valid syntax errors. E.g. if variable is missing a "$" infront > of it while assigning a value. This is not catched by bash. Is there a > more specific option that should be specified to bash to check for > syntax errors. > > Regards, > Ken > > ### example code > p=hello > e=world > If [ p != $e ];then > echo "not equal" > else > echo "equals" > fi [...] The error in your code is that you left $e unquoted. In list context (as in the arguments of a simple command like "["), an unquoted variable is treated as list of file patterns, not a litteral string. [ p != "$e" ] as you want to check if the value of $e is "p". Another error is the "then" without a "if" (you spelled it "If"). Note that "[" is a simple command that is not considered any different by bash from "echo" for instance. So, if echo p != $e ] is valid syntax, so is [ p != $e ] Of course you don't need to quote string litterals as in some other languages, as otherwise you'd need to write: "echo" "p" "!=" $e (remember that "echo", "p"... are all only arguments to the echo command, none is treated differently from the other as far as the shell is concerned) The usage of quotes can be very confusing in most Bourne like shells as it's completely different (almost the opposite) from other languages. In shell, you generally need to put quotes around variables, and generally don't need to put them around litterals. Quotes really fit a different purpose from in other languages. It's not for "typing", it's to prevent some special behaviors (like expansions or splitting). I'd suggest you read some litterature about shell syntax and quoting in particular. -- Stéphane
RE: bash -n doesn't seem to catch all syntax errors...
So how can bash script syntax be verified that includes shopt??? Is there more option on bash syntax command-line check that would make it identify this grammar??? Thanks for the quick reply. Regards, Ken -Original Message- From: Andreas Schwab [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 16, 2007 10:14 AM To: Ken Failbus Cc: bug-bash@gnu.org Subject: Re: bash -n doesn't seem to catch all syntax errors... "Ken Failbus" <[EMAIL PROTECTED]> writes: > bash -x /tmp/mydummy > + shopt -s extglob > + rm -f '/tmp/file.+([0-9])' > + exit 0 > > But if "bash -n" is run it doesn't understands +([0-9}) > bash -n /tmp/mydummy > /tmp/mydummy: line 3: syntax error near unexpected token `/tmp/file.+([' > /tmp/mydummy: line 3: `rm -f /tmp/file.+([0-9])' > > Can you provide insight into this. shopt changes the shell grammar. When it's not executed the modified grammar is not accepted. 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."
RE: bash -n doesn't seem to catch all syntax errors...
Thanks for your reply. That would certainly help. Regards, Ken -Original Message- From: Chet Ramey [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 16, 2007 9:51 PM To: Ken Failbus Cc: Andreas Schwab; bug-bash@gnu.org; [EMAIL PROTECTED] Subject: Re: bash -n doesn't seem to catch all syntax errors... Ken Failbus wrote: > So how can bash script syntax be verified that includes shopt??? > Is there more option on bash syntax command-line check that would make it identify this grammar??? One uses the `-O' invocation option to enable and disable shopt options at execution time. You would use `bash -O extglob -n scriptname'. 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/
