Re: [Oorexx-devel] Unix shells

[CVBruce]

When UNIX was originally released the default shell was /bin/sh, the Bourne 
Shell written by Stephen Bourne.  Make that the only shell.  As new shells were 
written and added to the system, if they were backward compatible, they would 
end up having /bin/sh linked to them.  I would never expect /bin/sh to be 
linked to a shell that wasn’t backwards compatible to Bourne shell, i.e. 
/bin/sh —> /bin/csh.

For portability reasons, I think using /bin/sh everywhere would provide the 
most portable programs, because you don’t assume greater functionality than the 
Bourne Shell.  If you need some other shell, then you specify it, such as René 
suggestion of the shell subcommand.

I think that most standards are that way too, POSIX, UNIX, etc.

My $0.02 worth.

Bruce

> On Apr 19, 2017, at 1:32 PM, Erich Steinböck  
> wrote:
> 
> 2. default shell
> 
> Our code currently hard-codes the default shell for AIX to be "ksh", for SUN 
> to be "sh", and for all other Unix's to be "bash".  Shouldn't the default be 
> "sh" all the time?  With "sh" supposedly being symlinked to the preferred 
> shell for the specific platform?



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Unix shells

[Rony G. Flatscher]

Just another remark/question in this context. On Unix operating systems there 
is an environment
variable SHELL defined that gives the fully qualified path to the shell 
program. AFAIUI this is
meant to be the default shell to be used for executing shell scripts, if there 
is no hashbang line
in a shell script.

Therefore I would have expected that ooRexx would use that shell variable's 
value by default, and in
the case that it is not set fall back to a default shell, maybe relative to the 
Unix system running.

---rony


On 19.04.2017 22:32, Erich Steinböck wrote:
> I'm intending to fix [bugs:1430]  
> with attached patch
> (which also fixes the broken no-shell Unix subcommands "command", and "cmd", 
> and adds subcommand
> handling for shells "dash", "tcsh", and "zsh").
>
> Before doing so, I'd like to discuss two things:
>
> 1. bash shortcut for Linux calling /bin/sh
>
> Our code in SystemCommands.cpp contains a special shortcut just for the 
> "bash" subcommand handler
> in a conditional #ifdef LINUX section.  This shortcut calls system(), which 
> in turn calls
> /bin/*sh* to execute the command.  This makes it impossible e. g. an Ubuntu 
> system, which symlinks
> /bin/sh to /bin/dash, to send a subcommand to /bin/bash.
>
> Subcommands other than "bash" are handled separately by fork()-ing and then 
> execl()-executing the
> command instead of calling system()).
>
> Does anyone know why we have this shortcut section?  Any idea why it could be 
> required?  Are there
> any known advantages/disadvantages in using system() instead of fork() / 
> execl()?
>
> The shortcut (only) also does some return code modulo 256 processing, that 
> I'd like to understand
> when/how it's required.
>
>
> 2. default shell
>
> Our code currently hard-codes the default shell for AIX to be "ksh", for SUN 
> to be "sh", and for
> all other Unix's to be "bash".  Shouldn't the default be "sh" all the time?  
> With "sh" supposedly
> being symlinked to the preferred shell for the specific platform?
>
> That could also answer René's request for a new "shell" subcommand handler, 
> that would select the
> preferred shell.
>
>
> Thanks for your thoughts.
> Erich
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Unix shells

[Rick McGuire]

On Wed, Apr 19, 2017 at 4:32 PM, Erich Steinböck  wrote:

> I'm intending to fix [bugs:1430]
>  with attached patch (which
> also fixes the broken no-shell Unix subcommands "command", and "cmd", and
> adds subcommand handling for shells "dash", "tcsh", and "zsh").
>
> Before doing so, I'd like to discuss two things:
>
> 1. bash shortcut for Linux calling /bin/sh
>
> Our code in SystemCommands.cpp contains a special shortcut just for the
> "bash" subcommand handler in a conditional #ifdef LINUX section.  This
> shortcut calls system(), which in turn calls /bin/*sh* to execute the
> command.  This makes it impossible e. g. an Ubuntu system, which symlinks
> /bin/sh to /bin/dash, to send a subcommand to /bin/bash.
>
> Subcommands other than "bash" are handled separately by fork()-ing and
> then execl()-executing the command instead of calling system()).
>
> Does anyone know why we have this shortcut section?  Any idea why it could
> be required?  Are there any known advantages/disadvantages in using
> system() instead of fork() / execl()?
>
> The shortcut (only) also does some return code modulo 256 processing, that
> I'd like to understand when/how it's required.
>

I don't know if this code has been touched much from the original code
received from IBM, so I doubt it is possible to answer any of these
questions. The bash bypass sounds like a definite bug to me, so it would be
good to fix this up. I suspect this area could really use a complete
cleanup by someone who understands the issues.


>
>
> 2. default shell
>
> Our code currently hard-codes the default shell for AIX to be "ksh", for
> SUN to be "sh", and for all other Unix's to be "bash".  Shouldn't the
> default be "sh" all the time?  With "sh" supposedly being symlinked to the
> preferred shell for the specific platform?
>
> That could also answer René's request for a new "shell" subcommand
> handler, that would select the preferred shell.
>

This sounds good to me, but I'm far from being a *ix expert.

Rick

>
>
> Thanks for your thoughts.
> Erich
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel