1

A script like:

#!/usr/bin/env bash
...
or
#!/usr/bin/env python3
...

will result in (german):

-bash: /mnt/Fritz-USB/FritzUSB/t.sh: /usr/bin/env: Defekter Interpreter: Eingabe-/Ausgabefehler

translated:

-bash: /mnt/Fritz-USB/FritzUSB/t.sh: /usr/bin/env: Bad Interpreter: I/O-Error

This only happens on a PC running ubuntu 22.04 on a PC running ubuntu 18.04 everything works as expected. It happens (on 22.04) with every (valid) shebang!

The Mounting options are equal on both systems (except closetimeo=1, which is not available on 18.04).

On ubuntu 22.04 the script will work if started as (or similar):

bash /mnt/Fritz-USB/FritzUSB/t.sh

If I copy the script onto another mount it will work:

cp /mnt/Fritz-USB/FritzUSB/t.sh /mnt/NAS/t.sh


/mnt/NAS/t.sh <-no error

I searched the web, but had no luck. maybe someone here has an idea.

Thanks

EDIT: Today I tried a "normal" prg on that drive. It turns out, that althougth that this don't run on the (Fritz-Box) cifs mout. When using a cifs mount of the local atached USB-drive everything works.

So the problem must be the kind the mount reacts. Because there is no difference between both PCs when using "findmnt -T", I belive it is a problem whith samba on the server side . I will ask the AVM-support if they know something about.

Neiß Günter
  • 41
  • 1
    Does it also happen if your shebang doesn't use env? Do #!/bin/bash or #!/bin/python fail the same way? What about if you launch the script with /usr/bin/env bash /mnt/Fritz-USB/FritzUSB/t.sh? That it works when copied is really weird. In both cases, it is on an external filesystem that is mounted locally, right? So /usr/bin/env refers to your local /usr dir, correct? – terdon Mar 28 '24 at 15:57
  • Yes, it happens whatever vaild path is after the shebang. – Neiß Günter Mar 29 '24 at 06:56
  • @terdon Yes, it happens whatever vaild path is after the shebang. And Yes I have mounted: a) The Fritz-Box (cifs vers 3.11) and b) USB-HD's. Something interesting is, that xattr doesn't work on a!. – Neiß Günter Mar 29 '24 at 07:03
  • As far as I understood shebang, it's handeled by a kernel exec-func. This checks for the "magic" and in case of the shebang it executes the "rest of the line". Maybe the never kernel on Ubuntu 20.04 makes the difference ? 22.04 uses 6.5.0-26-generic, 18.04 uses 5.4.0-174-generic – Neiß Günter Mar 29 '24 at 07:07
  • "If I copy the script onto another mount it will work:" - might there be a "automatic" CR+LF feature on the 'non-working' device ? is there a 0D 0A for the first linefeed in the output of $ od -t x1z /mnt/Fritz-USB/FritzUSB/t.sh | head -n 10 – Hannu Mar 29 '24 at 07:15
  • @Hannu No, there is no "line ending problem", hexdump shows only \n & because it works on another PC this should not be the problem – Neiß Günter Mar 29 '24 at 07:47
  • Well, that was one possible cause. What is clear is: If an unchanged script behaves differently depending on where it is fetched / read from, then the script itself isn't involved. – Hannu Mar 29 '24 at 08:06
  • To clarify >> if the code that implements shebang:ing reads the first line and gets ... bash<CR><LF>, removes the expected but not the ; then you will get the described fault. – Hannu Mar 29 '24 at 08:12
  • Let us continue this discussion in chat. – Neiß Günter Mar 29 '24 at 13:27
  • The output of findmnt -T /mnt/Fritz-USB/ and findmnt -T /mnt/NAS/ might help. – Raffa Mar 29 '24 at 20:58

0 Answers0