Re: Should this be this way?
Chet Ramey wrote: On 3/1/13 5:04 PM, Linda Walsh wrote: Chet Ramey wrote: Your vendor, which may be SuSE, has changed bash and shipped the modified version. Supposedly this has to do with memory corruption problems in 4.2 and the possibility that it might come back... I think you mean bash-3.2. The bug report is five years old. It sounds like the SuSE change might be there for quite a while, because, even though it's fixed, the problem could always come back. I do wonder why only SuSE exhibits the problem. --- I put forth the possibility that the reason for the bug in the first place the possibility of some, no longer relevant patch, at that time, in some other piece of code (perhaps not even in bash, but in some linking library) causing unpredictable behavior. The idea of carrying around every patch ever done, didn't seem sound. FWIW, resolution: Security team has have reviewed the rbash vector and consider it not relevant. rbash is not really a security protection anyway (think perl -e 'system(./a.out);') Also werner has submitted a bash that disables the patch for openSUSE Factory. So it looks like it will be gone after 12.3. I mentioned to them that if they thought rbash wasn't relevant for them, they could disable building it.
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
Chet Ramey wrote: The default bash behavior and the SuSE modification are both conformant. Is 'rbash' not part of POSIX? I.e. if I run in a restricted shell, it is consider POSIX compliant to elevate the user to /bin/sh when executing unlabeled script lines? Sorta makes the idea of a restricted shell a bit less useful.
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
On 14 March 2013 14:52, Linda Walsh b...@tlinx.org wrote: Is 'rbash' not part of POSIX? I think you misunderstand what POSIX Is. bash in general is not part of POSIX, neither is any other shell (other than the POSIX shell, which is purely theoretical). It has POSIX compliant features when run in POSIX compliance mode. For the record running rbash without a chroot does not make any sense in reality, it's usually easy to break out of. See my answer here: http://unix.stackexchange.com/a/59394/10762 Chris
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
On Wed, Mar 13, 2013 at 11:52:54PM -0700, Linda Walsh wrote: Sorta makes the idea of a restricted shell a bit less useful. Honestly, a restricted shell is usually a pitiful thing that would be a joke, except it's not even funny. It's what people tried to use for security back in like 1990 when nobody had a clue about security. Typically the users find a way out of the restricted shell within a couple hours by trying shell escapes in every command available to them (man page viewer, text editor, etc.) until one of them works. I have no idea what the POSIX standard has to do with your question, though.
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
On 3/14/13 2:52 AM, Linda Walsh wrote: Chet Ramey wrote: The default bash behavior and the SuSE modification are both conformant. Is 'rbash' not part of POSIX? Posix has chosen not to standardize the restricted shell, either `rsh' or `set -r'. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
On Tue, Mar 12, 2013 at 12:37 AM, Linda Walsh b...@tlinx.org wrote: Pierre Gaston wrote: It is likely that the document is assuming you are running on a POSIX compliant system where all users use the same shell so there is only 1 shell, thus the use of the word 'the' when referring to the shell. Of course, it's the posix specification for the posix shell What does that say about bash (in nonposix mode), perl, python, rbash, etc i.e. -- the case that I ran into was NOT me running in posix mode. Not much the bash part was covered by quoting the manual. No part of this email was about you, I was merely answering to Roman about the fact that it is specified in the 2 documents that are somehow relevant on this mailing list. It would make no sense for posix to take the stance that any unknown script without a shebang at the top, presented to any interpreter shell be ignored by the interpreter and instead shall be run under /bin/sh. Posix used to claim they were descriptive, not prescriptive, though they are becoming more of the latter with each new update, I'd find it hard to think they'd try to enforce all script languages to default sources to /bin/sh. Afaik Posix doesn't impose anything on anyone but those who want to claim being posix compliant. (and yeah perl and python don't try to be compliant with the posix shell specification).
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
On 3/11/13 6:37 PM, Linda Walsh wrote: It would make no sense for posix to take the stance that any unknown script without a shebang at the top, presented to any interpreter shell be ignored by the interpreter and instead shall be run under /bin/sh. The Posix shell specification only talks about the Posix shell. Likewise, Posix takes no position on whether or not shells offer extensions beyond the Posix-specified functionality. There are no other Posix interpreters (well, ok, there's awk). The likelihood of users attempting to run a script written in an arbitrary non-shell language without a #! from the shell prompt is quite small, so it's reasonable for the standard to contain what it does. The standard attempts to codify existing historical practice. Posix used to claim they were descriptive, not prescriptive, though they are becoming more of the latter with each new update, I'd find it hard to think they'd try to enforce all script languages to default sources to /bin/sh. You're entitled to your opinion. The fact remains, though, that this same language, or something very similar, has been in the Posix standard since 1992. As I said above, it attempts to standardize historical practice. The default bash behavior and the SuSE modification are both conformant. The more interesting question is why SuSE feels the need to do this. The original bug report from five years ago admits that it's not a solution to the underlying SuSE-specific problem, just a workaround. Subseqent comments admit that the problem has been fixed for quite a while, but may reappear at any time. I find this unconvincing, but it's not the first time a vendor has changed bash, not documented the result, and declined to revisit the decision. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
ignoring current shell and always running posix shell? Re: Should this be this way?
Pierre Gaston wrote: On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus rra...@redhat.com wrote: I think the line above will produce unspecified behavior. Man bash says: If this execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script, a file containing shell commands. A subshell is spawned to execute it. This subshell reinitializes itself, so that the effect is as if a new shell had been invoked to handle the script, with the exception that the locations of commands remembered by the parent (see hash below under SHELL BUILTIN COMMANDS) are retained by the child. I doubt that starting a different shell than the one you are running under is going to preserve commands in the same way as the parent UNLESS the parent is the same shell. Has passing such hashed args been standardized between zsh/tcsh,ksh /sh/bash? SUS says If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2008, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of $0 in the new shell may be set to the command name. If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and shall return an exit status of 126. It is likely that the document is assuming you are running on a POSIX compliant system where all users use the same shell so there is only 1 shell, thus the use of the word 'the' when referring to the shell. Question -- is the above behavior required everywhere? I.e. if you are executing python or perl and execute something without a #!, then the posix shell would be started? What is the user is running /bin/rsh or /bin/rbash? I.e. if the wording *truly* indicates that /bin/sh is the correct answer, under any interpretation, then that seems to imply that such is true when running under rbash/rsh, as they are not mentioned as exceptions.
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
On Mon, Mar 11, 2013 at 7:11 PM, Linda Walsh b...@tlinx.org wrote: Pierre Gaston wrote: On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus rra...@redhat.com wrote: I think the line above will produce unspecified behavior. Man bash says: If this execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script, a file containing shell commands. A subshell is spawned to execute it. This subshell reinitializes itself, so that the effect is as if a new shell had been invoked to handle the script, with the exception that the locations of commands remembered by the parent (see hash below under SHELL BUILTIN COMMANDS) are retained by the child. I doubt that starting a different shell than the one you are running under is going to preserve commands in the same way as the parent UNLESS the parent is the same shell. Correct, that's why bash doesn't do that (at least an upstream not patched version that the manual is documented) Has passing such hashed args been standardized between zsh/tcsh,ksh /sh/bash? I don't know SUS says If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2008, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of $0 in the new shell may be set to the command name. If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and shall return an exit status of 126. It is likely that the document is assuming you are running on a POSIX compliant system where all users use the same shell so there is only 1 shell, thus the use of the word 'the' when referring to the shell. Of course, it's the posix specification for the posix shell
Re: ignoring current shell and always running posix shell? Re: Should this be this way?
Pierre Gaston wrote: It is likely that the document is assuming you are running on a POSIX compliant system where all users use the same shell so there is only 1 shell, thus the use of the word 'the' when referring to the shell. Of course, it's the posix specification for the posix shell What does that say about bash (in nonposix mode), perl, python, rbash, etc i.e. -- the case that I ran into was NOT me running in posix mode. It would make no sense for posix to take the stance that any unknown script without a shebang at the top, presented to any interpreter shell be ignored by the interpreter and instead shall be run under /bin/sh. Posix used to claim they were descriptive, not prescriptive, though they are becoming more of the latter with each new update, I'd find it hard to think they'd try to enforce all script languages to default sources to /bin/sh.
Re: Should this be this way?
Chet Ramey wrote: Your vendor, which may be SuSE, has changed bash and shipped the modified version. Supposedly this has to do with memory corruption problems in 4.2 and the possibility that it might come back... Is this likely to be a problem? Dr. Werner Fink wrote: The patch belongs to memory corruption ahd happen with several bug reports like: http://bugzilla.novell.com/show_bug.cgi?id=382214 http://bugzilla.novell.com/show_bug.cgi?id=384175 that is that after the siglongjmp() the bash had showed memory corruption. This seems to be fixed in bash 4.2 ... nevertheless it could come back again as memory management together with setjmp()/longjmp() or sigsetjmp()/siglongjmp() has to managed thorough to not run into the same problems as in the bugs above. This is the only reason why this patch is still alive. And yes I've read the thread http://www.mail-archive.com/bug-bash@gnu.org/msg12269.html
Re: Should this be this way?
On 3/1/13 5:04 PM, Linda Walsh wrote: Chet Ramey wrote: Your vendor, which may be SuSE, has changed bash and shipped the modified version. Supposedly this has to do with memory corruption problems in 4.2 and the possibility that it might come back... I think you mean bash-3.2. The bug report is five years old. It sounds like the SuSE change might be there for quite a while, because, even though it's fixed, the problem could always come back. I do wonder why only SuSE exhibits the problem. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Should this be this way?
On 2/27/13 11:05 PM, Linda Walsh wrote: Greg Wooledge wrote: How often, when at a terminal, do you type #!/bin/bash before every line? When I've put the contents into a file? Every. single. time. --- Then when I press 'v' to edit the command line in a text editor -- maybe 'bash' should insert such a line? It's converted your command line into an editable file. But it hasn't put the #!/bin/bash at the front. This is a bad example. The file that is the result of the vi-mode `v' command is run as if it were sourced with `.'. It's not run as if it were a shell script. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Should this be this way?
Chet Ramey wrote: Linda Walsh wrote: Greg Wooledge wrote: How often, when at a terminal, do you type #!/bin/bash before every line? When I've put the contents into a file? Every. single. time. --- Then when I press 'v' to edit the command line in a text editor -- maybe 'bash' should insert such a line? It's converted your command line into an editable file. But it hasn't put the #!/bin/bash at the front. This is a bad example. The file that is the result of the vi-mode `v' command is run as if it were sourced with `.'. It's not run as if it were a shell script. Ah! There is the answer. Don't run it as a script. Always source these files instead. . ./file When sourced they will run in the context of the current bash shell and the behavior will be as expected. I say that somewhat tongue-in-cheek myself. Because sourcing files removes the abstraction barriers of a stacked child process and actions there can persistently change the current shell. Not good as a general interface for random actions. Normal scripts are better. Bob Who still remembers when if the exec(2) failed then the shell examined the first character. If it was a '#' then shell ran the file through csh. If ':' then through ksh. If neither then sh. This may have been a local hack though. Clearly the Berkeley #! hack is better.
Re: Should this be this way?
Bob Proulx b...@proulx.com writes: I say that somewhat tongue-in-cheek myself. Because sourcing files removes the abstraction barriers of a stacked child process and actions there can persistently change the current shell. Not good as a general interface for random actions. Normal scripts are better. You can still put the sourcing in a subshell if you don't want persistent changes. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Should this be this way?
On Thu, Feb 28, 2013 at 7:09 PM, Andreas Schwab sch...@linux-m68k.org wrote: Bob Proulx b...@proulx.com writes: I say that somewhat tongue-in-cheek myself. Because sourcing files removes the abstraction barriers of a stacked child process and actions there can persistently change the current shell. Not good as a general interface for random actions. Normal scripts are better. You can still put the sourcing in a subshell if you don't want persistent changes. ehe, or just bash script
Re: Should this be this way?
On Thu, Feb 28, 2013 at 09:55:01AM -0700, Bob Proulx wrote: Who still remembers when if the exec(2) failed then the shell examined the first character. If it was a '#' then shell ran the file through csh. If ':' then through ksh. If neither then sh. This may have been a local hack though. Clearly the Berkeley #! hack is better. the other way round :) # was the Berkeley hack implemented in both sh and csh. #! was the Bell Labs hack, but the first systems to implement this outside Bell Labs were running in Berkeley. (I haven't heard of such a ksh hack, yet. Would like to hear more, off-list if you like)
Re: Should this be this way?
Chet Ramey wrote: On 2/27/13 11:05 PM, Linda Walsh wrote: Greg Wooledge wrote: How often, when at a terminal, do you type #!/bin/bash before every line? When I've put the contents into a file? Every. single. time. --- Then when I press 'v' to edit the command line in a text editor -- maybe 'bash' should insert such a line? It's converted your command line into an editable file. But it hasn't put the #!/bin/bash at the front. This is a bad example. The file that is the result of the vi-mode `v' command is run as if it were sourced with `.'. It's not run as if it were a shell script. === It's not rocket science to think that you don't want to keep hopping back and forth from the command line to a GUI editor, so a logical progression would have many people saving the file into /tmp/xxx, chmod +x /tmp/xxx; gvim /tmp/xxx ; ... and continue... People are used to side-by-side development looking at source and running in another window, so as soon as people start opening a cmd line in an external editor, it's quite rational to assume that some percentage of them will save the file and continue work as a normal workflow. It isn't one I use every day, but may scripts start out as 1 liners that grow and are saved into files. If I save the script in a 'bin' directory, I add the header, but if it's in /tmp, it's not the first thing I'm thinking about.
Re: Should this be this way?
Chet Ramey wrote: Your vendor, which may be SuSE, has changed bash and shipped the modified version. Sorry for the bother. I reported the problem in the proper venue... (thanks)..
Re: Should this be this way?
Greg Wooledge wrote: How often, when at a terminal, do you type #!/bin/bash before every line? When I've put the contents into a file? Every. single. time. --- Then when I press 'v' to edit the command line in a text editor -- maybe 'bash' should insert such a line? It's converted your command line into an editable file. But it hasn't put the #!/bin/bash at the front. If that file is saved and run, it doesn't execute the same way as it does interactively. (note, I say the above someone tongue-in-cheek, but only to point out that it's very easy to go from editing a command to a file and if it becomes a file and 'bash' might not execute it the same way w/o the header, maybe it should put a headerline in? ;^/ ... (maybe distro's shouldn't muck w/user's shells...)...
Re: Should this be this way?
On 2013-02-27 20:05, Linda Walsh wrote: (maybe distro's shouldn't muck w/user's shells...)... You're using SuSE, which is basically guaranteeing that your programs are mangled in unexpected ways. Then again, it's as bad of an offender as Debian, and most other distributions, I guess... Chris
Re: Should this be this way?
On 02/26/2013 02:03 AM, Linda Walsh wrote:
My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well.
Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash.
which is not always correct. Use type builtin.
I had the foll0wing script which acts differently based on
whether or not it has a #!/bin/bash at the top: (i.e., as it is
displayed below, it fails; one need remove the [] from the first
line for it to work.
#[!/bin/bash]
I think the line above will produce unspecified behavior.
while read fn;do
base=${fn%.*}
if [[ -e $base ]]; then
if [[ $base -ot $fn ]]; then echo compressed version ($fn) seems newer
elif [[ $base -nt $fn ]]; then echo uncompressed version ($base)
seem newer
else echo both versions ($base) are same age
fi
else
echo No uncompressed version of $base exists
fi
done (find . -type f -name \*.[0-9].\*[zZ]\* )
-
The error:
./manscan.sh: line 12: syntax error near unexpected token `'
./manscan.sh: line 12: `done (find . -type f -name \*.[0-9].\*[zZ]\* )'
Why would this script behave differently if the first line
exists or not? (Putting the !shell in square brackets,
made it a comment, not an interpreter spec, thus the same
effect as if it wasn't there ('cept the line number of the error is 1
less if you don't have the line! ;-)).
So...is this correct behavior for some[inane POSIX] reason?
Seems a bit odd to me.
Is kernel or bash processing the shebang?
RR
Re: Should this be this way?
On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus rra...@redhat.com wrote: On 02/26/2013 02:03 AM, Linda Walsh wrote: My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well. Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash. which is not always correct. Use type builtin. I had the foll0wing script which acts differently based on whether or not it has a #!/bin/bash at the top: (i.e., as it is displayed below, it fails; one need remove the [] from the first line for it to work. #[!/bin/bash] I think the line above will produce unspecified behavior. I think the kernel will try to find a shebang and not recognize it, then the current shell will try to run it Man bash says: If this execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script, a file containing shell commands. A subshell is spawned to execute it. This subshell reinitializes itself, so that the effect is as if a new shell had been invoked to handle the script, with the exception that the locations of commands remembered by the parent (see hash below under SHELL BUILTIN COMMANDS) are retained by the child. SUS says If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2008, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of $0 in the new shell may be set to the command name. If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and shall return an exit status of 126.
Re: Should this be this way?
On 2/26/13 12:41 AM, Linda Walsh wrote: It isn't using the current value of SHELL as my shell nor the value of my login shell. It uses $0 (or, rather, the basename of $0), which is initialized from the parent shell's argv[0]. What is $0 set to? It is forcing interpretation into /bin/sh, which I don't use. Not quite. It is enabling posix mode. There are a couple of ways to do that: $POSIXLY_CORRECT, $0 == sh, or set -o posix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Should this be this way?
Chet Ramey wrote:
On 2/26/13 12:41 AM, Linda Walsh wrote:
It isn't using the current value of SHELL as my shell nor the value
of my login shell.
It uses $0 (or, rather, the basename of $0), which is initialized from
the parent shell's argv[0]. What is $0 set to?
-bash
It is forcing interpretation into /bin/sh, which I don't use.
Not quite. It is enabling posix mode. There are a couple of ways to
do that: $POSIXLY_CORRECT, $0 == sh, or set -o posix.
---
Not doing either of those here...
I do have MAN_POSIXLY_CORRECT so man only gives me 1 man page followed
by the section numbers of other man pages, as opposed to acting like
'less' with multiple files (i.e. next to go to next page)...
But I don't see anything that would suggest to to bash to flip into shell.
The code that the original poster pointed me at doesn't appear to
have a check for what shell it was invoked as (or what is in $0).
It seems to go off the fact that line 0 didn't have an interpreter
line specified...
I.e., what I see is:
#next line is #5033
/* Is this supposed to be an executable script?
If so, the format of the line is #! interpreter [argument].
A single argument is allowed. The BSD kernel restricts
the length of the entire line to 32 characters (32 bytes
being the size of the BSD exec header), but we allow 80
characters. */
if (sample_len 0)
{
#if !defined (HAVE_HASH_BANG_EXEC)
if (sample_len 2 sample[0] == '#' sample[1] == '!')
return (execute_shell_script (sample, sample_len, command, args, env));
else
#endif
if (check_binary_file (sample, sample_len))
{
internal_error (_(%s: cannot execute binary file), command);
return (EX_BINARY_FILE);
}
}
/* We have committed to attempting to execute the contents of this file
as shell commands. */
#if 1 ---Note problem??
(SuSE ism?)
larray = strvec_len(args) + 1;
args = strvec_resize(args, larray + 1);
for (i = larray - 1; i; i--)
args[i] = args[i - 1];
args[0] = savestring(_PATH_BSHELL);
args[1] = command;
args[larray] = (char *)0;
SETOSTYPE (0);/* Some systems use for USG/POSIX semantics */
execve (/bin/sh, args, env);
SETOSTYPE (1);
internal_error (_(%s: cannot execute: %s), command, strerror (errno));
#else
initialize_subshell ();
set_sigint_handler ();
/* Insert the name of this shell into the argument list. */
larray = strvec_len (args) + 1;
args = strvec_resize (args, larray + 1);
for (i = larray - 1; i; i--)
args[i] = args[i - 1];
args[0] = shell_name;
args[1] = command;
args[larray] = (char *)NULL;
if (args[0][0] == '-')
args[0]++;
#if defined (RESTRICTED_SHELL)
if (restricted)
change_flag ('r', FLAG_OFF);
#endif
if (subshell_argv)
{
/* Can't free subshell_argv[0]; that is shell_name. */
for (i = 1; i subshell_argc; i++)
free (subshell_argv[i]);
free (subshell_argv);
}
dispose_command (currently_executing_command);/* XXX */
currently_executing_command = (COMMAND *)NULL;
subshell_argc = larray;
subshell_argv = args;
subshell_envp = env;
unbind_args (); /* remove the positional parameters */
longjmp (subshell_top_level, 1);
/*NOTREACHED*/
#endif
return (EX_NOEXEC);
}
Re: Should this be this way?
POSIX specifies the behavior of a shell. This tells Chet how he has to make Bash behave (with some leeway). There are all kinds of silly little details and ambiguities that Chet has to worry about. However, YOU as a shell script writer do not have to worry about all that crap. All you have to do is put the proper shebang line in your script, and then -- like magic! -- your script will be executed using the interpreter you specified. End of problem.
Re: Should this be this way?
Greg Wooledge wrote: POSIX specifies the behavior of a shell. This tells Chet how he has to make Bash behave (with some leeway). There are all kinds of silly little details and ambiguities that Chet has to worry about. However, YOU as a shell script writer do not have to worry about all that crap. All you have to do is put the proper shebang line in your script, and then -- like magic! -- your script will be executed using the interpreter you specified. --- Except it isn't a script -- it's input that came from the terminal, that got repetitively edited using vi mode, until it got saved in a file so it could continue to be edited, and stay on the screen while executing it in the original window. I.e. it's the natural evolution of input you type into the terminal. How often, when at a terminal, do you type #!/bin/bash before every line? To have your script suddenly change behavior because you saved it in a file and executed it by name would probably surprise most people.
Re: Should this be this way?
On Tue, Feb 26, 2013 at 01:27:35PM -0800, Linda Walsh wrote: Except it isn't a script -- it's input that came from the terminal, that got repetitively edited using vi mode, until it got saved in a file so it could continue to be edited, and stay on the screen while executing it in the original window. If it's in a file, it is a script. Do note that commands in a file are not equivalent to commands typed into an interactive shell. If the commands set variables or change directory or toggle shell options, those changes won't persist because you're running a script, and they go away when the script terminates. Maybe you want a shell function instead. How often, when at a terminal, do you type #!/bin/bash before every line? When I've put the contents into a file? Every. single. time.
Re: Should this be this way?
On 2/26/13 3:39 PM, Linda Walsh wrote: Chet Ramey wrote: On 2/26/13 12:41 AM, Linda Walsh wrote: It isn't using the current value of SHELL as my shell nor the value of my login shell. None of this is relevant, see below. #if 1 ---Note problem?? Your vendor, which may be SuSE, has changed bash and shipped the modified version. They have chosen to interpret Posix (a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand) as requiring that bash actually invoke /bin/sh, with all of the consequences of starting a fresh process. I imagine they didn't change the man page while they were at it, nor produce a list somewhere of the changes they made. I'm always going to answer from the perspective of bash as I distribute it. This is a different case. You should follow Greg's excellent advice and include the #! line. That's the only way you can be sure of what you get. (SuSE ism?) larray = strvec_len(args) + 1; args = strvec_resize(args, larray + 1); for (i = larray - 1; i; i--) args[i] = args[i - 1]; args[0] = savestring(_PATH_BSHELL); args[1] = command; args[larray] = (char *)0; SETOSTYPE (0); /* Some systems use for USG/POSIX semantics */ execve (/bin/sh, args, env); SETOSTYPE (1); internal_error (_(%s: cannot execute: %s), command, strerror (errno)); Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Should this be this way?
On Mon, Feb 25, 2013 at 8:03 PM, Linda Walsh b...@tlinx.org wrote:
My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well.
Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash.
I had the foll0wing script which acts differently based on
whether or not it has a #!/bin/bash at the top: (i.e., as it is
displayed below, it fails; one need remove the [] from the first
line for it to work.
#[!/bin/bash]
while read fn;do
base=${fn%.*}
if [[ -e $base ]]; then
if [[ $base -ot $fn ]]; then echo compressed version ($fn) seems
newer
elif [[ $base -nt $fn ]]; then echo uncompressed version ($base)
seem newer
else echo both versions ($base) are same age
fi
else
echo No uncompressed version of $base exists
fi
done (find . -type f -name \*.[0-9].\*[zZ]\* )
-
The error:
./manscan.sh: line 12: syntax error near unexpected token `'
./manscan.sh: line 12: `done (find . -type f -name \*.[0-9].\*[zZ]\* )'
Why would this script behave differently if the first line
exists or not? (Putting the !shell in square brackets,
made it a comment, not an interpreter spec, thus the same
effect as if it wasn't there ('cept the line number of the error is 1
less if you don't have the line! ;-)).
So...is this correct behavior for some[inane POSIX] reason?
Seems a bit odd to me.
How are you calling the script without a shebang? Bash called as sh does
disable some bashisms, process substitution being one of them.
Re: Should this be this way?
On Mon, Feb 25, 2013 at 8:12 PM, Linda Walsh b...@tlinx.org wrote: Sorry, forgot: bash --version GNU bash, version 4.2.10(1)-release (x86_64-suse-linux-gnu) uname -a Linux Ishtar 3.7.6-Isht-Van #4 SMP PREEMPT Thu Feb 7 01:34:39 PST 2013 x86_64 x86_64 x86_64 GNU/Linux --- I just can see why it should execute differently... very weird. You didn't answer the question... how did you call the script? ''sh script'' ?
Re: Should this be this way?
DJ Mills wrote: On Mon, Feb 25, 2013 at 8:12 PM, Linda Walsh b...@tlinx.org mailto:b...@tlinx.org wrote: You didn't answer the question... how did you call the script? ''sh script'' ? --- I typed the script name interactively on the command line -- the way I thought most people ran scripts. I mentioned that everything in my ENV and usage pointed at /bin/bash. Why would I do that, and then use 'sh script'? Wouldn't that sorta be deliberately misleading?
Re: Should this be this way?
On 2013-02-25 18:27, Linda Walsh wrote: I mentioned that everything in my ENV and usage pointed at /bin/bash. You gave $SHELL, which is not really relevant (it doesn't necessarily reference your login shell, or your current shell either). Why would I do that, and then use 'sh script'? Wouldn't that sorta be deliberately misleading? You'd be surprised what people do without thinking about it. Seems like a well-intentioned question to me, at least. Either way, the code you're looking for is in `shell_execve' in `execute_cmd.c', it should explain the behaviour that you're seeing. It's very well commented, you should be able to find your answer there. Chris
Re: Should this be this way?
Chris Down wrote: On 2013-02-25 18:27, Linda Walsh wrote: I mentioned that everything in my ENV and usage pointed at /bin/bash. You gave $SHELL, which is not really relevant (it doesn't necessarily reference your login shell, or your current shell either). I also gave my login shell and that bash was in my current path, I thought that the default in executing a shell script was to use my login or $SHELL value .. that both of them were the same was my point. Why would I do that, and then use 'sh script'? Wouldn't that sorta be deliberately misleading? You'd be surprised what people do without thinking about it. Seems like a well-intentioned question to me, at least. *sigh* Either way, the code you're looking for is in `shell_execve' in `execute_cmd.c', it should explain the behaviour that you're seeing. It's very well commented, you should be able to find your answer there. --- Yup... It isn't using the current value of SHELL as my shell nor the value of my login shell. It is forcing interpretation into /bin/sh, which I don't use. This brings me back to the original question... Should this be this way? I think it is a bit odd to have my default shell behavior NOT be what is in my login nor in my SHELL variable - I found it confusing to have some alien shell semantics applied to my shell and couldn't figure out how it got what it got... Um... RFE? Maybe execute the program under whatever shell they are currently running as?
Re: Should this be this way?
On Tue, Feb 26, 2013 at 3:03 AM, Linda Walsh b...@tlinx.org wrote:
My login shell is /bin/bash (i.e. not /bin/sh); SHELL=/bin/bash as well.
Typing 'which bash' gives /bin/bash, and whence bash: bash is /bin/bash.
I had the foll0wing script which acts differently based on
whether or not it has a #!/bin/bash at the top: (i.e., as it is
displayed below, it fails; one need remove the [] from the first
line for it to work.
#[!/bin/bash]
while read fn;do
base=${fn%.*}
if [[ -e $base ]]; then
if [[ $base -ot $fn ]]; then echo compressed version ($fn) seems newer
elif [[ $base -nt $fn ]]; then echo uncompressed version ($base)
seem newer
else echo both versions ($base) are same age
fi
else
echo No uncompressed version of $base exists
fi
done (find . -type f -name \*.[0-9].\*[zZ]\* )
-
The error:
./manscan.sh: line 12: syntax error near unexpected token `'
./manscan.sh: line 12: `done (find . -type f -name \*.[0-9].\*[zZ]\* )'
Why would this script behave differently if the first line
exists or not? (Putting the !shell in square brackets,
made it a comment, not an interpreter spec, thus the same
effect as if it wasn't there ('cept the line number of the error is 1
less if you don't have the line! ;-)).
So...is this correct behavior for some[inane POSIX] reason?
Seems a bit odd to me.
I don't seem to be able to reproduce it with my default configuration.
However I can reproduce it by setting (but not exporting) POSIXLY_CORRECT
