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

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, th

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 whe

Re: ignoring current shell and always running posix shell? Re: Should this be this way?

On 14 March 2013 14:52, Linda Walsh 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 compl

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

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 on

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 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 refer

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 specificati

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 wrote: > Pierre Gaston wrote: >> On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus 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 t

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 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 > scr

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 bas

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 bel

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 tex

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 thou

Re: Should this be this way?

On Thu, Feb 28, 2013 at 7:09 PM, Andreas Schwab wrote: > Bob Proulx 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 gen

Re: Should this be this way?

Bob Proulx 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.

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 -- > >

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 '

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?

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

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?

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 <-

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

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

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 d

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"

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

Re: Should this be this way?

On Tue, Feb 26, 2013 at 11:22 AM, Roman Rakus 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 bui

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

Re: Should this be this way?

On Tue, Feb 26, 2013 at 3: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. > > I had the foll0wing script which acts differently based on > whether or not it has a #!/bin/

Re: Should this be this way?

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 co

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'? > > Wou

Re: Should this be this way?

DJ Mills wrote: > On Mon, Feb 25, 2013 at 8:12 PM, Linda Walsh > 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 m

Re: Should this be this way?

On Mon, Feb 25, 2013 at 8:12 PM, Linda Walsh 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

Re: Should this be this way?

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.

Re: Should this be this way?

On Mon, Feb 25, 2013 at 8:03 PM, 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. > > I had the foll0wing script which acts differently based on > whether or not it has a #!/bin

Should this be this way?

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; on