Re: IBM z/OS compatibility issues - shell environment

["Daniel Richard G." <skunk@iSKUNK.ORG>]

On Sun, 2019 Nov 17 22:24-05:00, Bruno Haible wrote:
> > 
> > The problem, however, is that shell scripting with this version
> > of Bash can be a little tricky, because it doesn't fully
> > embrace EBCDIC. ... These are the settings I used which allow
> > things to work:
> > 
> >     _ENCODE_FILE_NEW=IBM-1047
> >     _ENCODE_FILE_EXISTING=IBM-1047
> >     _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"
> >     _BPXK_AUTOCVT=ON
> >     _TAG_REDIR_ERR=txt
> >     _TAG_REDIR_IN=txt
> >     _TAG_REDIR_OUT=txt
> 
> Can we have this documented in the column "Other variables" of
> https://gitlab.com/ghwiki/gnow-how/wikis/Platforms/Configuration ?

It's quite a bit of verbiage to stick into a table cell! Might a
separate page be appropriate? Scripts could give the URL to it in
lieu of a more descriptive error message if they detect breakage
related to this.

> > While I would not recommend giving to init.sh knowledge of the above
> > variables, I think it would be helpful to do some basic sanity
> > checking (like the echo|grep invocation above) to avoid more
> > pathological breakage later in the script. The failure message could
> > include a hint to the user about what's wrong with the shell, and
> > what needs to be done to fix it.
>
> The 'echo ABC | grep ABC > /dev/null' command is indeed something that
> we could check in a number of shell scripts. In which shell scripts do
> you wish it to be added?

When /bin/sh is used to build Gnulib, everything works great. The
top-level configure run and most other incidental shell scripts are
covered by this.

It's only when a shell script decides "/bin/sh is junk, I want bash"
that trouble arises. And when I do a standard "./configure && make &&
make check" run, this doesn't happen until it gets to test-atexit.sh.
What is notable about that one is that it appears to be the first
shell-script test that sources init.sh.

Here is what appears on the console when I attempt to run this test
manually, with the Rocket build of bash in my PATH:

    $ env srcdir=/tmp/testdir/gltests /tmp/testdir/gltests/test-atexit.sh 
    expr: non-numeric argument "@@@@@??@"
    /tmp/testdir/gltests/init.sh: line 366: test: ?: integer expression expecd
    expr: non-numeric argument "?"
    /tmp/testdir/gltests/init.sh: line 366: test: 4: unary operator expected
    Usage: expr expression
    /tmp/testdir/gltests/init.sh: line 366: test: 4: unary operator expected
    Usage: expr expression
    /tmp/testdir/gltests/init.sh: line 366: test: 4: unary operator expected
    Usage: expr expression
    /tmp/testdir/gltests/init.sh: line 366: test: 4: unary operator expected
    Usage: expr expression
    /tmp/testdir/gltests/init.sh: line 366: test: 4: unary operator expected
    Usage: expr expression
    [continues on forever]

The init.sh script starts off in /bin/sh but looks for and executes
bash, presumably to obtain more advanced shell functionality.

Even before trying to fix this, I'm wondering: Is this really necessary?
The place where it gets stuck above is in the mktempd_() shell function,
which provides the functionality of a missing mktemp(1). Given that this
is running in a build tree, wouldn't something like prefix$$ be enough?

If that can't be helped, then at least init.sh should perform this
sanity check. I see that there is already some shell-checking in place
via gl_shell_test_script_; perhaps this could be an added check. I hope
a helpful error message can be part of it too.


--Daniel


-- 
Daniel Richard G. || skunk@iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.