Command line confusion - #2

Discussions in English on using Fedora
#1

Again, I have migrated from Manjaro to Fedora. Suddenly my backup invocation command refuses to work. I have no idea why!

[tomc@localhost bkup]$ ls -1
backup-all
backup-all2
[tomc@localhost bkup]$ backup-all2
bash: backup-all2: command not found
[tomc@localhost bkup]$ sh backup-all2
sh: backup-all2: No such file or directory
[tomc@localhost bkup]$ sh backup-all2.sh
sh: backup-all2.sh: No such file or directory
[tomc@localhost bkup]$ ./backup-all2
bash: ./backup-all2: No such file or directory
[tomc@localhost bkup]$

As this IS my backup routine I urgently need it to launch.

Can anyone tell me what I don’t grasp here?

2 Likes
#2

Check the output:

file backup*
ldd backup*

See also:

#3

Please post the result of
ls -l

Note -l (l, the letter, Lima) and not -1 (- one).

Probably these files don’t have the execution bit (x).

2 Likes
#4

Missing executable bit returns a permission denied error.

2 Likes
#5

I think this is partially a path problem. In the command or script replace “backup-all2” with “/path/to/backup-all2” Also make certain you use the full filename. If it is backup-all2.sh then use that full file name. Also, everything is case sensitive so be certain that if the file is named Backup-All2 that your command spells it exactly that way.

Unlike windows that will execute files with a .bat or .exe filename without using that extension, when on Linux it is quite literal and requires the full path and file name to run them.

You can if you wish modify the $PATH variable to include the path to backup-all2??? as well.
You would need the file to have at minimum 700 permissions in order to execute it and most people use 750.

Did you try “sh ./backup-all2” That might have worked.

Can you post the content of backup-all2?
Also the result of “ls -l”

1 Like
#6

First, thanks to all of you who responded so quickly to my issue, and with such a range of ideas. I worked through most of them, then found the problem and fixed it. My backup is flying along now, as I write this.

I invoke my backup script in my account root, and it is actually a link to the actual backup script, in another directory. THERE the problem was found: in copying my several backup scripts over from my previous OS, all the execution bits got turned off! Turning them back on, the backup runs as it should.

I have seen this happen before, but don’t know why it happens. in this case, I merely restored to my new OS’s file tree the files in the daily backup of my account on my previous OS. At what point the execution bit got turned off I have no idea.

All is welll now. Thanks again for your generous and speedy response.

4 Likes
#7

Since I got bitten by something similar before:
I usually create a ~/bin directory in my home and add that directory to the $PATH. Then any script I write that will be run by me goes there, and anything that will be run by root or all users goes to /usr/local/bin. No more linking.

2 Likes
#8

This is a factor of the users umask combined with the default system security. On files, simply copying them to a new location using cp without the proper options will always turn off the execute bits as well as changing the ownership of the new file to the user performing the copy.
As your regular user (and as root if you use the su command) you can use the umask command to see and reset that users umask
I think on most systems the regular user has a default umask of 0022 which masks out the write bit for both group and other on both files and directories. The system automatically masks out the execute bit for all on files but leaves it in for directories.

What this means overall is that if you copy an executable file – either a script or a binary – and you want the new copy to be executable and retain ownership, you will need to use the appropriate options to the copy command used or be prepared to manually reset those on the copy just made.

2 Likes
#9

For Reference, File Permissions and Attributes Arch Wiki

1 Like
#10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.