*|FNAME|*

So, latest #Linux weirdness:

I have a series of commands ‘VMBoxManage’ that I want to call from a cron job.

If I execute the commands as my user, no issue. If I execute the commands as a cron job (as my user) no issue. If I put the commands in a nice tidy bash script, and call it from the CLI or cron, no worky. (Command not found)

EDIT: actual error message is “cannot execute: required file not found”

I currently have it working with a massive, ugly command in cron. (I.e. /usr/bin/command1 && /usr/bin/command2 &&…) but it’s ugly.

How fix?

Mar 18 at 10:03pmWeb
Show thread*|FNAME|*2d ago

I think I might have fixed it.

The .sh file started its life as a DOS text file. This will apparently cause problems.
#Linux

Show threadHello, my name is Disappoint2d ago
@crispius Well, that's just stupid.
Show thread*|FNAME|*2d ago
@ZenHeathen
That’s what happens when you mix environments. 🤷‍♂️
Show threadIan McDowall2d ago
@crispius not the old CR / CR LF trick? I forgot about that one.
Or some other issue?
Show thread*|FNAME|*2d ago
@imcdowall
Exactly that.
Show threadfelix2d ago
@crispius Did you forget the shebang at the top of the script?
Show thread*|FNAME|*2d ago
@felix
Nope.
Show threadCarl 2d ago
@crispius You might need to check your PATH variable. You can set it in the crontab file, or in the script itself. Another option would be to make the calls to VMBoxManage use the full path. You can find it by running 'which VMBoxMange' in a terminal.
Show thread*|FNAME|*2d ago
@carlt4
Calling with the full path.
Show threadSebastiaan2d ago
@crispius That it started as a DOS thing has no issue. System cron runs as a user with a different $PATH variable (less filled). Check / update your PATH settings in the affected file(s)
Show thread*|FNAME|*2d ago
@sebastiaanfranken
Fixed. Create new .sh file, copy contents from old file into it. Make executable. Bingo.
Show threadSebastiaan2d ago
@crispius Glad it's fixed! Weird that that fixed it though, since that should have no effect *at all*, unless something else was also going on at the same time (SELinux context, user/group ownership, etc). Anyway, I'm diving into this unneeded haha
Show thread*|FNAME|*2d ago

@sebastiaanfranken
from the page where I found the solution:

"Your demo.sh script is a DOS text file. Such files have CRLF line endings, and that extra CR (carriage-return) character at the end of the line is causing you issues.

The specific issue it's causing is that the interpreter pathname on the #!-line now refers to something called /bin/bash\r (with the \r symbolising a carriage-return, which is a space-like character, so it's usually not visible). This file is not found, so this is what causes your error message."

Show threadSebastiaan2d ago
@crispius Yeh that's partially BS, but I'll leave it for now. You can by the way convert it with "dos2unix" (from the package by the same name), or use vim ("vim <filename> -c 'set ff=unix' -c ':wq'") The vim one opens the file, sets the file ending to unix and enters the ":wq" command (write and quit)
Show threadCome On Giant Asteroid!1d ago

@crispius

Ummm … rusty synapses … something-something user that owns the shell that is running the script …

Show thread*|FNAME|*1d ago
@VE2UWY
It’s solved.