bash dash zsh sh and co | crontab | why so complicated
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
bash dash zsh sh and co | crontab | why so complicated
Apparently I still don't quite understand what the individual shells are all about. Again and again I have the problem that scripts don't work properly.
As an example my script completed today ( A part of it ):
When I run the script ( my system Deepin linux, Debian ),
sh lockfile.sh
my lockfile is created correctly! but then the program terminates with the error message : 'testlock.sh: 1: exec: 99: not found'.
Ok, it seems to be that sh cannot start exec..?
If I start with
bash lockfile.sh
my lockfile is not created, but no error message appears.
It's different when I do it on Ubuntu
bash testlock.sh' works.
Under CRON, however, it doesn't work there again, and I have to set it up with 'sh .../testlock.sh'
To be honest, I don't understand.
I thought about the shebang, I say exactly in what context I want to do this?
Can you please enlighten me and give me some examples on how to deal with such problems.
In addition to what that says and in response to you question about shells. Each shell or interpreter has its own characteristics. You should specify the one you want in the interpreter line of your script.
sh by itself is a bit vague as it might be a reference to the original Bourne shell OR to the more recent Posix shell (on UNIX) or a symbolic link to another shell (e.g. on Linux it might be linked to bash or dash depending on your distro and version). Rather than risking it not being what you expect rather than using interpreter line as:
Code:
#!/bin/sh
Use something like the following to explicitly set which shell you want:
Code:
#!/bin/bash
Last edited by MensaWater; 04-16-2018 at 11:31 AM.
I read both your link and your answer, but to be honest, it doesn't help me a lot.
I had already written that I knew I was giving the'Shell' with the'Shebang'.
Still, it doesn't explain the difference in behavior.
At last I just want the script to run, I don't know how to make sure it does.
Could you explain to me how I notice in an environment X, how I call a script correctly?
The link says THAT you have to call it up correctly, but not HOW, as so many articles before.
Additionally, it seems, for example, that certain common script commands can be executed in the'Bash', but not when I do this via 'sh'. Which is how you say just a shortcut to'dash' or something similar.
Is there any literature in which I can read, for example, :
If I am in an environment X, then the call must be ' command X' and 'command Y' under Crontab or initab.
How do I know which commands work under'bash' and which don't?
Thank God! Finally I found an appropriate explanation for the problem with the crontab.
Environment variables!
If I add 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' to the beginning of the crontab, the script works.
This website is really cool. https://www.digitalocean.com/communi...g-my-sh-script
Interesting that you say my link didn't help when it highlights PATH as a common issue and you later say adding PATH solved your issue.
You seem to be under the misunderstanding that the PATH will always have the same value. It won't - you have to figure out which directories contain the executables you want and insure those directories are in the PATH. You can blindly add directories and in some cases that may find what you need or you can spend time understanding what YOUR script needs and tailor its environment.
Also, if you want to (& you should) use a specific shell eg 'bash', just put that in the first line of the file (ie shebang as you do) but DON'T the preface the call with 'sh' eg 'sh myfile.sh' ; just use '/path/to/myfile.sh'.
probably you missed: when you execute a script like: bash lockfile.sh the shebang will be ignored, the script will be executed by bash, what you specified. Similarly: <shell> <script> will always use <shell> to run <script>. shell can be python/perl/whatever/anything which can run text files.
Shebang will be taken into account if you execute the script directly, without specifying the interpreter to use.
From the other hand different shells [may] have different syntax. I suggest you to try shellcheck to validate your script.
Quote:
Ok, it seems to be that sh cannot start exec..?
is definitely a wrong statement, it is just an (syntactically?) incorrect script.
Quote:
do you agree with
#!/usr/bin/env bash over
#!/bin/bash ?
env should only be used if you have no idea about the location of the interpreter you want to use. Otherwise it is just an unnecessary overhead.
In Linux, sh is invariably a link to another program. Traditionally this program is bash, but Debian and all its derivatives (Ubuntu, Mint, etc) use dash. You can find out what sh points to on your system by typing readlink /bin/sh.
Because of these variations it's usually a bad idea to use sh to run your own scripts. Use the actual shell name instead and make sure you are using the correct syntax for that shell. Bash in particular has some extra commands that won't work in dash.
this is not that simple. If I know well bash/dash/... will recognize if they were invoked using sh or bash (or rbash or ...) and will behave accordingly/differently.
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,195
Rep:
Quote:
Originally Posted by pan64
this is not that simple. If I know well bash/dash/... will recognize if they were invoked using sh or bash (or rbash or ...) and will behave accordingly/differently.
I am not sure about that. I have been bitten a few times by starting a script with #!/bin/sh which was executed by dash instead of bash. That is about 10 years ago or so and happened after Debian linked sh to dash instead of bash by default. Ever since I use #!/bin/bash. With the complete path name that is.
In cron jobs I also use the complete path name. Even if a path is specified. It might be overkill but often I specify /bin/bash /path/to/my/script so I am sure it runs Bash, no matter what the shebang says.
Furthermore especially to OP: I think it is an extremely bad idea to have "?" or "*" characters in a file name. I know, in some situations Bash can be made to handle "*" in filenames. But why make life harder than it is.
I think it is an extremely bad idea to have "?" or "*" characters in a file name. I know, in some situations Bash can be made to handle "*" in filenames. But why make life harder than it is.
I agree but don't see where the OP was using either meta-character in a file name.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.