request
1. Missing quotes
#
[me@linuxbox me]$ ./trouble.bash
./trouble.bash: line 8430: unexpected EOF while looking for matching "
./trouble.bash: line 8440 systax error: unexpected end of file
#
We have 2017, please add suggestions for errors
For example for "
#===
VAR=$(cat file | sed 's/[^"]//g' | awk '{ print length }' | cat -n | grep
"[13579]$" | awk '{print $1}')
echo "We suggest check $VAR"
echo "because this lines of file, contain an odd number of quotes "
#===
2. Please hide e-mail for google bots, or remove this e-mail after read.
Thanks !:-)
bug in cd
I'm not even sure if cd is part of Bash? anyway - if you type any of the following: cd / ; pwd cd /// ; pwd cd ; pwd the CLI always reports / but, if you do this: cd // ; pwd then the CLI reports // -- Kae Verens http://kvsites.ie/
Re: bug in cd
On 7/14/17 7:14 AM, Kae Verens wrote: > I'm not even sure if cd is part of Bash? It is. It's a regular shell builtin. > anyway - if you type any of the following: > cd / ; pwd > cd /// ; pwd > cd ; pwd > > the CLI always reports > / > > but, if you do this: > cd // ; pwd > > then the CLI reports > // Posix requires this behavior: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html#tag_20_14 step 8c. Two leading slashes must be preserved, because // has implementation- defined semantics. Any other number may be collapsed to one slash. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: request
On Fri, Jul 14, 2017 at 11:09:25AM +0200, t wrote: > # > [me@linuxbox me]$ ./trouble.bash > ./trouble.bash: line 8430: unexpected EOF while looking for matching " > ./trouble.bash: line 8440 systax error: unexpected end of file Your problem is that your script is about 8300 lines longer than it should be. Writing a bash script that's over ~100 lines is crazy. Yours is over 8000 lines. I have no words. > echo "We suggest check $VAR" > echo "because this lines of file, contain an odd number of quotes " But lines are explicitly *allowed* to contain an odd number of quotes. This is how multi-line string constants are created. body="This is the body of an email. It has multiple lines. There are so many words that they don't all fit on one line." When the parser encouters a syntax error, it *cannot* know where the real problem is; only that there *is* one, somewhere. You as the programmer have to be the one to track it down and fix it. You know that the syntax error originates somewhere *on* or *before* the line number where the parser hit the brick wall and stopped. That's all you know. You don't know whether it's actually a missing quote. It could be a missing } or a missing fi or a missing esac or a missing done, or ANY OTHER missing or incorrect syntax element. That is *one* of the reasons why bash scripts should be kept small. > 2. Please hide e-mail for google bots, or remove this e-mail after read. Screw you. (And yes, this is the sanitized version.)
Re: /bin/sh should set SHELL to /bin/sh
Date:Thu, 13 Jul 2017 23:02:49 -0400 From:Chet Ramey Message-ID: <102d254a-d321-20c0-b8d6-9f2257861...@case.edu> | Posix, the closest thing we have to a standard description of SHELL, says: It does, but POSIX doesn't say the shell is intended to set it. That is, it defines its purpose, but leaves unstated where it comes from. IMO, if SHELL gets unset (it is usually initialised by login, or its equivalent), it should simply stay unset, and not be set to anything, until some user (or script) decides to set it again. kre
Re: /bin/sh should set SHELL to /bin/sh
On Sat, Jul 15, 2017 at 02:59:41AM +0700, Robert Elz wrote: > IMO, if SHELL gets unset (it is usually initialised by login, or its > equivalent), it should simply stay unset, and not be set to anything, > until some user (or script) decides to set it again. wooledg:~$ unset SHELL wooledg:~$ bash -c 'echo "$SHELL"' /bin/bash wooledg:~$ ksh -c 'echo "$SHELL"' /bin/sh wooledg:~$ zsh -c 'echo "$SHELL"' wooledg:~$ tcsh -c 'echo "$SHELL"' SHELL: Undefined variable. Looks like there's not much agreement here.
Re: /bin/sh should set SHELL to /bin/sh
On 07/14/2017 03:13 PM, Greg Wooledge wrote: > On Sat, Jul 15, 2017 at 02:59:41AM +0700, Robert Elz wrote: >> IMO, if SHELL gets unset (it is usually initialised by login, or its >> equivalent), it should simply stay unset, and not be set to anything, >> until some user (or script) decides to set it again. > > wooledg:~$ unset SHELL > wooledg:~$ bash -c 'echo "$SHELL"' > /bin/bash > wooledg:~$ ksh -c 'echo "$SHELL"' > /bin/sh > wooledg:~$ zsh -c 'echo "$SHELL"' > > wooledg:~$ tcsh -c 'echo "$SHELL"' > SHELL: Undefined variable. > > Looks like there's not much agreement here. > Good thing is bash doesn't export SHELL if it wasn't already exported, and most shells seem to preserve the value of SHELL exported by some parent. I see mksh sets -x if SHELL was previously unset... I suppose that might cause a problem in some scenario (but probably not). signature.asc Description: OpenPGP digital signature
