2

I embarrassed myself a little here with a simple typo and a profound ignorance. Save yourself some grief:

  1. your hasbangs/shebangs must always have a leading /, such as #!/bin/bash
  2. be precise
  3. if you are working between host and guest (virtual) machine without copy-and-paste enabled, just stop. Typos will kill your code and your question, (which can p_ss people off). Figure out how to get copy-and-paste working, or work from the one machine. Manually retyping is folly.
  4. be grateful. There are really quite helpful people here.
  5. they're all linux, but different distros can have idiosyncrasies when it comes to shells and scripts. (This includes full and minimal versions of the distro). Check your shell (ps -p$$ -ocmd= worked for me source). Do you have to create directories manually (esp. in minimal distros)?
  6. for me, because its the most applicable to most systems (i.e "portable"), I'm going to start my scripts with #!/usr/bin/env <SHELL>, where SHELL is bash, sh, or whatever. Lots of how-to websites just seem to say "always start your script with #!/bin/bash" with no explanation or caveat. Just not true.
  7. Shellcheck. This tool may be quite helpful. (Credit - roaima)

I cannot get scripts to run in a Lubuntu (Xenial) Minimal (+LXDE) VM with shebangs - without, they're fine.

Following advice in a previous post, I have made a very simple script, in 4 versions that differ only in the shebang:

echotest (no shebang line):

#blantantly simple test to figure out script problems

echo "this is working - type something for me to repeat it"
read input
echo $input

echotest-bin-bash

#!bin/bash

#blantantly simple test to figure out script problems

echo "this is working - type something for me to repeat it"
read input
echo $input

and two more, corresponding to #!bin/dash and [EDIT: inserted "bin" in the following, in this text not the script] #!bin/sh.

These files are saved in ~/bin, a directory that I created manually after reading a forum somewhere.

Testing the scripts from there yields:

x@computer:~$ echotest
this is working - type something for me to repeat it
test1
test1

i.e. it works without any shebang, but

x@computer:~$ echotest-bin-bash
bash: /home/x/bin/echotest-bin-bash: bin/bash: bad interpreter: No such file or directory
x@computer:~$ echotest-bin-dash
bash: /home/x/bin/echotest-bin-dash: bin/bash: bad interpreter: No such file or directory
x@computer:~$ echotest-bin-sh
bash: /home/x/bin/echotest-bin-sh: bin/sh: bad interpreter: No such file or directory

Further,

x@computer:~$ ./echotest-bin-bash
bash: ./echotest-bin-bash: No such file or directory

To test another recommendation I read on a forum/blog, I removed the scripts from ~/bin and tried them while saved in /usr/local/bin.

x@computer:~$ echotest
bash: /home/x/bin/echotest: No such file or directory

And the same for all the other variants.

However,

x@computer:~$ sudo /usr/local/bin/echotest
this is working - type something for me to repeat it
test
test

(i.e. it works)

x@computer:~$ sudo /usr/local/bin/echotest-bin-bash
sudo: unable to execute /usr/local/bin/echotest-bin-bash: No such file or directory
Hangup

Note, all permissions have been granted with either chmod +x <filename> or more rarely, chmod 777 <filename>, and double-checked with ls -l /rele/vant/directory.

x@computer:~$ echo $PATH
/home/x/bin:/home/x/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

In answer to a previous response on my first attempt at this question, Lubuntu Minimal shows these installed:

||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  dash           0.5.8-2.1ubu amd64        POSIX-compliant shell

ii  bash           4.3-14ubuntu amd64        GNU Bourne Again SHell

Using commands I do not fully understand, gleaned from forums:

x@computer:~$ file "$(type -P bash)" 2>/dev/null
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=[redacted for the forum], stripped

x@computer:~$ type -p bash
/bin/bash 

Murphy, if you're reading - I have no luck trying to call up bin/bash, getting a prompt. I don't know how and my search terms bring up too much off-target material.

Finally, I tested the functioning script (i.e. without the shebang), in a .desktop file, and it functioned perfectly (Exec=echotest).

Why don't the shebangs work? Equivalent scripts with the #!bin/bash work just fine in my Ubuntu Mate (Xenial) host.

I am sure this is a very basic error, but I'm stumped. This is my second ever script, so I am happy to be directed to relevant basic materials.

Thanks in advance

Edit

Thanks Jesse_b.

Edit1.1 - no, I'm wrong. #!/bin/bash does work. I have searched the terminal history and I cannot find that entry I referred to previously.

Also, #!/usr/bin/env bash works perfectly.

Edit 2

Thanks Murphy

Using a hashbang #!/bin/sh and #!/bin/bash work just fine.

Further

x@computer:~$ ls -l /bin/bash
-rwxr-xr-x 1 root root 1037528 May 16  2017 /bin/bash

x@computer:~$ /usr/bin/env | grep bash
SHELL=/bin/bash

x@computer::~$ ls -l /bin/*sh
-rwxr-xr-x 1 root root 1037528 May 16  2017 /bin/bash
-rwxr-xr-x 1 root root  154072 Feb 17  2016 /bin/dash
lrwxrwxrwx 1 root root       4 May 16  2017 /bin/rbash -> bash
lrwxrwxrwx 1 root root       4 Feb 17  2016 /bin/sh -> dash

A final edit - different distros will be more or less strict on how your hashbangs/shebangs are formatted. I found this post wherein someone describes similar problems with an earlier versions of Mint/Xfce and Lubuntu/LXDE.

(I ran into troubles when I manually re-typed a script in my host Ubuntu Mate into a Lubuntu Minimal/LXDE guest. I thought I observed different behaviour between distros, but a) I didn't understand the significance of the shebang format, b) there are websites that offer maybe-not-so-good advice, and c) I am prone to typos. As an experiment, see if your script will work without a shebang at all.)

  • j doe, you're still not telling the whole story. What exactly does ls -l /bin/bash show - better yet ls -l /bin/*sh? Give us the copy/pasted output. Addtionally, what's the output of /usr/bin/env | grep bash? And what about executing /bin/bash, now including the leading slash (You know the difference between relative and absolute paths, do you?)? What about #!/bin/sh? – Murphy Dec 16 '17 at 16:54
  • Hi Murphy - I've amended the post. the ls and `grep' commands you ask for give me the impression that while root owns these things, anyone can execute. No? The leading slash was the problem for me, a very noob mistake. Should I delete this and the other question or leave them for someone else to learn from? – j doe will do just fine Dec 16 '17 at 21:23
  • You don't need to keep writing "Edit". This isn't a forum, and we have full edit history available on all questions and answers. Instead, ideally you would (re)write your question with the new information included in such a way that it flowed seamlessly like your first version would have done. Remember, on this site you're not just looking for an answer but you're writing a readable question for future readers to say, "Ah, that's my problem too... and look: they got an answer that works for me!" – roaima Dec 19 '17 at 23:22
  • ...And that's why it's helpful to accept the answer that helps you most, because it points readers to a potentially "most useful" answer. – roaima Dec 19 '17 at 23:26
  • By the way, you would probably find shellcheck.net very helpful. – roaima Dec 19 '17 at 23:26
4

Your hash bang must start with the leading forward slash /

#!bin/bash is almost certainly not a valid directory/file path and should be #!/bin/bash

If you're unsure that a shell exists, you could always use ls or something to ensure the path is correct, or a more portable way to write it would be:

#!/usr/bin/env bash

This will cause the system to automatically lookup the path of bash (or whatever interpreter you chose) via env and use the first one it finds.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.