Hi, I wasted a whole afternoon figuring out why a job that runs ok on many opensuse machines fails on a machine that runs a debian alpha distribution (customer demand). I already had to fix all kind of startup scripts due to the fact that sh(ell scripts) are run with dash which is incompatible so maybe I should have be more suspicious towards the os instead of trying to fix the tex end. Anyhow, one thing I noticed is that setuptex doesn't seem to work ok i.e. there is something wrong with determining $OWNPATH which makes the initialization fail. Maybe some volunteer can figure that out (there are some catches for other shells in the script too so adding yet another doesn't hurt). But, the biggest surprise (if I got it right) is that in some of the scripts that I use and run from within context, the to be produced results sometimes were there and sometimes not. This got obscured by the fact that in a second run the content actually was there (it has to be fetched from a remote database) but that code like "page \pagenumber\ of \lastpage" failed to report the right last page which in fact was a side effect of the first run not using content. Okay, it got somewhat more obscured by the fact that I used --runs=2 Accidentally, by adding more tracing code, I figured out is that I pipe the messages to a log file using &> which is pretty valid in bash but not so in dash where the & puts the job in the background and thereby let the tex run carry on without waiting. So, it looks like we need to use >filename 2>&1 instead of &>filename. I checked the scripts in the context tree and so far found no occurences but first-setup.sh has two &>'s in it that might need fixing. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 10/30/2012 01:20 PM, Hans Hagen wrote:
filename 2>&1
This has been the correct Bourne shell (POSIX) syntax for many years. I think it goes all the way back to Bell Labs V7 IIRC
instead of &>filename.
is a "bash-ism"
I checked the scripts in the context tree and so far found no occurences but first-setup.sh has two &>'s in it that might need fixing.
Hans
-- Bill Meahan Westland, Michigan USA
On Tue 30 Oct 2012, Bill Meahan wrote:
On 10/30/2012 01:20 PM, Hans Hagen wrote:
filename 2>&1
This has been the correct Bourne shell (POSIX) syntax for many years. I think it goes all the way back to Bell Labs V7 IIRC
instead of &>filename.
is a "bash-ism"
FWIW, Debian and Ubuntu have a package ‘devscripts’ which includes a program ‘checkbashisms’ to catch such things (Ubuntu started using dash as the default sh back in 2006). Ubuntu also has some advice on strict-POSIX shell scripting: https://wiki.ubuntu.com/DashAsBinSh#I_am_a_developer._How_can_I_avoid_this_p... Pont
On 30-10-2012 18:38, Pontus Lurcock wrote:
On Tue 30 Oct 2012, Bill Meahan wrote:
On 10/30/2012 01:20 PM, Hans Hagen wrote:
filename 2>&1
This has been the correct Bourne shell (POSIX) syntax for many years. I think it goes all the way back to Bell Labs V7 IIRC
instead of &>filename.
is a "bash-ism"
FWIW, Debian and Ubuntu have a package ‘devscripts’ which includes a program ‘checkbashisms’ to catch such things (Ubuntu started using dash as the default sh back in 2006). Ubuntu also has some advice
hm, so i wonder why setuptex fails on that box then (not that i care much as i can set the path)
on strict-POSIX shell scripting: https://wiki.ubuntu.com/DashAsBinSh#I_am_a_developer._How_can_I_avoid_this_p...
yes but it renders past workflows pretty useless then .. anyway, someone has to adapt the installer scripts to such changes ok, context also changes, but a proper 'crash' is imo better than silent side effects .. in fact there the how-can is easy: use primitives only -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Tue 30 Oct 2012, Hans Hagen wrote:
FWIW, Debian and Ubuntu have a package ‘devscripts’ which includes a program ‘checkbashisms’ to catch such things (Ubuntu started using dash as the default sh back in 2006). Ubuntu also has some advice
hm, so i wonder why setuptex fails on that box then (not that i care much as i can set the path)
I was briefly confused as to why I (and other Ubuntu users) have never had a problem with setuptex... then I remembered that while sh links to dash (because it's fast), bash is still used explicitly as the default *login* shell (because it's featureful). So ‘source setuptex’ has always worked for me but would presumably give trouble in a non-login shell. Don't know how Debian does it. Pont
On 30-10-2012 18:50, Pontus Lurcock wrote:
On Tue 30 Oct 2012, Hans Hagen wrote:
FWIW, Debian and Ubuntu have a package ‘devscripts’ which includes a program ‘checkbashisms’ to catch such things (Ubuntu started using dash as the default sh back in 2006). Ubuntu also has some advice
hm, so i wonder why setuptex fails on that box then (not that i care much as i can set the path)
I was briefly confused as to why I (and other Ubuntu users) have never had a problem with setuptex... then I remembered that while sh links to dash (because it's fast), bash is still used explicitly as the default *login* shell (because it's featureful). So ‘source setuptex’ has always worked for me but would presumably give trouble in a non-login shell. Don't know how Debian does it.
It somehow also works for me (i occasionally use a xubuntu vm) using ". setuptex" but that doesn't seem to work from another script. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 30-10-2012 18:38, Pontus Lurcock wrote:
On Tue 30 Oct 2012, Bill Meahan wrote:
On 10/30/2012 01:20 PM, Hans Hagen wrote:
filename 2>&1
This has been the correct Bourne shell (POSIX) syntax for many years. I think it goes all the way back to Bell Labs V7 IIRC
instead of &>filename.
is a "bash-ism"
FWIW, Debian and Ubuntu have a package ‘devscripts’ which includes a program ‘checkbashisms’ to catch such things (Ubuntu started using dash as the default sh back in 2006). Ubuntu also has some advice on strict-POSIX shell scripting: https://wiki.ubuntu.com/DashAsBinSh#I_am_a_developer._How_can_I_avoid_this_p...
Mojca, we need to change such lines in first-setup: if which rsync &> /dev/null; then Maybe a dashing user can check it for more non posix things. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 30-10-2012 18:38, Pontus Lurcock wrote:
On Tue 30 Oct 2012, Bill Meahan wrote:
On 10/30/2012 01:20 PM, Hans Hagen wrote:
filename 2>&1
This has been the correct Bourne shell (POSIX) syntax for many years. I think it goes all the way back to Bell Labs V7 IIRC
instead of &>filename.
is a "bash-ism"
FWIW, Debian and Ubuntu have a package ‘devscripts’ which includes a program ‘checkbashisms’ to catch such things (Ubuntu started using dash as the default sh back in 2006). Ubuntu also has some advice on strict-POSIX shell scripting: https://wiki.ubuntu.com/DashAsBinSh#I_am_a_developer._How_can_I_avoid_this_p...
This also needs checking (in setuptex): if [ z"$BASH_SOURCE" != z ]; then SCRIPTPATH="$BASH_SOURCE" elif [ z"$KSH_VERSION" != z ]; then SCRIPTPATH="${.sh.file}" else SCRIPTPATH="$0" fi OWNPATH=$(cd -P -- "$(dirname -- "$SCRIPTPATH")" && pwd -P) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 30-10-2012 18:26, Bill Meahan wrote:
On 10/30/2012 01:20 PM, Hans Hagen wrote:
filename 2>&1
This has been the correct Bourne shell (POSIX) syntax for many years. I think it goes all the way back to Bell Labs V7 IIRC
instead of &>filename.
is a "bash-ism"
sure, till one replaces bash by something non-bash-ish while the user still thinks he's running bash (i always fear the moment that someone decides that swapping the 'cp' arguments without renaming the command is a good idea -) (i wouldn't be surprised if it can backfire badly in more complex situations) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 10/30/2012 01:39 PM, Hans Hagen wrote:
sure, till one replaces bash by something non-bash-ish while the user still thinks he's running bash (i always fear the moment that someone decides that swapping the 'cp' arguments without renaming the command is a good idea -)
(i wouldn't be surprised if it can backfire badly in more complex situations)
Hans
My background is in "commercial" Unix and I've had situations like having to administer an HP box (HPUX) a Sun box (Solaris) a Teradata box (some flavor or other of SYS V R4) some BSD and Linux on the same day. :) Only thing I could count on was the "official" AT&T Bourne shell syntax. I use ksh93 (the AT&T distribution) as my login shell. -- Bill Meahan Westland, Michigan USA
On 30-10-2012 22:33, Bill Meahan wrote:
On 10/30/2012 01:39 PM, Hans Hagen wrote:
sure, till one replaces bash by something non-bash-ish while the user still thinks he's running bash (i always fear the moment that someone decides that swapping the 'cp' arguments without renaming the command is a good idea -)
(i wouldn't be surprised if it can backfire badly in more complex situations)
Hans
My background is in "commercial" Unix and I've had situations like having to administer an HP box (HPUX) a Sun box (Solaris) a Teradata box (some flavor or other of SYS V R4) some BSD and Linux on the same day. :) Only thing I could count on was the "official" AT&T Bourne shell syntax.
I use ksh93 (the AT&T distribution) as my login shell.
This assumes control over the login shell as well as control over what the launchers of system processes use. I must admit that till now I always assumed some stability in this, which is probably okay as long as one sticks to one specific distribution (of linux). I think that the main problem is that #! /bin/sh can mean anything (although in your case I suppose you expect it to be the bourne shell). So the question is, should the scripts that come with context (like the installer) be explicit and become #! /bin/bash ? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, Oct 31, 2012 at 12:21 AM, Hans Hagen
On 30-10-2012 22:33, Bill Meahan wrote:
On 10/30/2012 01:39 PM, Hans Hagen wrote:
sure, till one replaces bash by something non-bash-ish while the user still thinks he's running bash (i always fear the moment that someone decides that swapping the 'cp' arguments without renaming the command is a good idea -)
(i wouldn't be surprised if it can backfire badly in more complex situations)
Hans
My background is in "commercial" Unix and I've had situations like having to administer an HP box (HPUX) a Sun box (Solaris) a Teradata box (some flavor or other of SYS V R4) some BSD and Linux on the same day. :) Only thing I could count on was the "official" AT&T Bourne shell syntax.
I use ksh93 (the AT&T distribution) as my login shell.
This assumes control over the login shell as well as control over what the launchers of system processes use. I must admit that till now I always assumed some stability in this, which is probably okay as long as one sticks to one specific distribution (of linux).
I think that the main problem is that #! /bin/sh can mean anything (although in your case I suppose you expect it to be the bourne shell).
So the question is, should the scripts that come with context (like the installer) be explicit and become #! /bin/bash ?
In my opinion, yes. And then bash first-setup.sh and source setuptex are ok. -- luigi
On 10/30/2012 07:21 PM, Hans Hagen wrote:
So the question is, should the scripts that come with context (like the installer) be explicit and become #! /bin/bash ?
Hans
If you're depending on specific syntax or features of bash, that would be the way to go. I suspect most/all Linux and BSD distributions come with bash, even if it's not the default shell. Solaris or HPUX or AIX not so much. Since I didn't always have root, I couldn't install bash even if I wanted to so I stuck to Bourne shell. KSH93 is a superset but 100% upwards compatible so anything written for the Bourne shell will run as expected. Not quite sure what PDKSH does. -- Bill Meahan Westland, Michigan USA
Hello, Am 31.10.2012 00:21, schrieb Hans Hagen:
This assumes control over the login shell as well as control over what the launchers of system processes use. I must admit that till now I always assumed some stability in this, which is probably okay as long as one sticks to one specific distribution (of linux).
There is stability in that /bin/sh always must be a (posix compatible) bourne (not again) style shell!
I think that the main problem is that #! /bin/sh can mean anything (although in your case I suppose you expect it to be the bourne shell).
A shell available as /bin/sh can have far more features but you can not rely on them!
So the question is, should the scripts that come with context (like the installer) be explicit and become #! /bin/bash ?
If the scripts do use bashisms they have to be declared with #! /bin/bash. So you do have this options: * rewrite the scripts to be truly posix and use #! /bin/sh (the dash links from another mail may help) * leave the scripts alone with all their bashisms and declare them with #! /bin/bash My advice on this is: in all shellscripts you write, declare the shell that you are testing the script with -- so on most linux systems (and in windows unix environments like msys) use /bin/bash and only change this to /bin/sh if you have to. For example to make it compatible to a minimal system (a jeos VM comes to mind) that is not supposed to provide /bin/bash. Uwe
On 1-11-2012 11:09, Uwe Koloska wrote:
Hello,
Am 31.10.2012 00:21, schrieb Hans Hagen:
This assumes control over the login shell as well as control over what the launchers of system processes use. I must admit that till now I always assumed some stability in this, which is probably okay as long as one sticks to one specific distribution (of linux).
There is stability in that /bin/sh always must be a (posix compatible) bourne (not again) style shell!
I think that the main problem is that #! /bin/sh can mean anything (although in your case I suppose you expect it to be the bourne shell).
A shell available as /bin/sh can have far more features but you can not rely on them!
So the question is, should the scripts that come with context (like the installer) be explicit and become #! /bin/bash ?
If the scripts do use bashisms they have to be declared with #! /bin/bash. So you do have this options:
* rewrite the scripts to be truly posix and use #! /bin/sh (the dash links from another mail may help) * leave the scripts alone with all their bashisms and declare them with #! /bin/bash
My advice on this is: in all shellscripts you write, declare the shell that you are testing the script with -- so on most linux systems (and in windows unix environments like msys) use /bin/bash and only change this to /bin/sh if you have to. For example to make it compatible to a minimal system (a jeos VM comes to mind) that is not supposed to provide /bin/bash.
add to this: don't use google cq. and don't look into other scripts to get an idea on what to do but buy a book on scripting (thinking of it: i might as well stick to lua scripts) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
2012-11-01 Uwe Koloska:
There is stability in that /bin/sh always must be a (posix compatible) bourne (not again) style shell!
True
* rewrite the scripts to be truly posix and use #! /bin/sh (the dash links from another mail may help) * leave the scripts alone with all their bashisms and declare them with #! /bin/bash
My advice on this is: in all shellscripts you write, declare the shell that you are testing the script with -- so on most linux systems (and in windows unix environments like msys) use /bin/bash and only change this to /bin/sh if you have to.
I do it the other way. Always write /bin/sh compatible scripts (actually first-setup.sh uses /bin/sh) and resort to /bin/bash if bash specific features save considerable effort.
For example to make it compatible to a minimal system (a jeos VM comes to mind) that is not supposed to provide /bin/bash.
FreeBSD comes without bash installed by default. The point is that it's easy for shell scripts like first-setup.sh that can easily declare the shell in the she-bang line. But setuptex cannot start a new well-defined shell since it's supposed to modify the current environment. That's why setuptex is sourced instead of executed. That however implies that setuptex has to conform to the current shell, which is unknown and needs to be guessed without relying on anything the shell might not provide. Marco
On Thu, 1 Nov 2012 12:10:58 +0100
Marco Patzer
2012-11-01 Uwe Koloska:
There is stability in that /bin/sh always must be a (posix compatible) bourne (not again) style shell!
True
* rewrite the scripts to be truly posix and use #! /bin/sh (the dash links from another mail may help) * leave the scripts alone with all their bashisms and declare them with #! /bin/bash
My advice on this is: in all shellscripts you write, declare the shell that you are testing the script with -- so on most linux systems (and in windows unix environments like msys) use /bin/bash and only change this to /bin/sh if you have to.
I do it the other way. Always write /bin/sh compatible scripts (actually first-setup.sh uses /bin/sh) and resort to /bin/bash if bash specific features save considerable effort.
For example to make it compatible to a minimal system (a jeos VM comes to mind) that is not supposed to provide /bin/bash.
FreeBSD comes without bash installed by default.
Whats more, bash is found under /usr/local/bin/bash on FreeBSD so #! /bin/bash is bound to FAIL. Best use posix standard scripting. There is no need for bashisms. Alan
On Thu 01 Nov 2012, Alan BRASLAU wrote:
Whats more, bash is found under /usr/local/bin/bash on FreeBSD so #! /bin/bash is bound to FAIL.
One traditional solution is to use #!/usr/bin/env bash This of course assumes the path to env, but I believe that the env path is more standardized than the bash path. (/usr/bin/env is valid on FreeBSD, for example.) Pont
participants (7)
-
Alan BRASLAU -
Bill Meahan -
Hans Hagen -
luigi scarso -
Marco Patzer -
Pontus Lurcock -
Uwe Koloska