4

I have this in my script. But is returning an error. If I execute the command in the console works fine

./script.sh[16]: mv: not found [No such file or directory]

I want move some files what starts in T353 from one folder to another. REMOTE_PATH is /tmp/ and PATH is my working directory

cd $REMOTE_PATH
mv T353* $PATH #this is the line 16

If I make mv /tmp/T353* . works fine.

Gilles 'SO- stop being evil'
  • 829,060
userGuest
  • 43
  • 1
  • 3

1 Answers1

20

You seem to be using the variable PATH in your script. This happens to be the variable that the shell uses to look up executables. This means that if you change it to something else which is not a :-delimited list of paths, or to a path that does not contain the executables that the script uses, the shell may no longer find things like mv or other standard utilities.

It is preferable to use lowercase letters in shell script variables for this reason (it's a matter of taste1), or to at least be aware that there are variable that the shell uses for various things, and that you should avoid modifying these unless, of course, you'd like to alter the shell's behaviour.

The variables that Bash uses are listed under the heading "Shell Variables" in the Bash manual.

Incidentally, the cd on the line above does work. It's because it's a special utility built into to shell itself. The shell thus does not have to look at $PATH to figure out where it is.

Also incidentally, you say that $PATH is your working directory. The shell already stores the current working directory in $PWD.

As a side note, make a habit of double-quoting your variables. See "Security implications of forgetting to quote a variable in bash/POSIX shells".

1 Well, mostly, but the POSIX standard reserves the namespace of uppercase variables for environment variables (i.e. exported shell variables) used by the shell and by the collection of standard utilities. AFAIK, it doesn't disallow the use of uppercase characters in non-exported shell variables, but the whole purpose of defining namespaces is to avoid clashes. Since, to a script, environment variables and shell variables have the same semantics, it's better to just avoid uppercase variables altogether.

Kusalananda
  • 333,661
  • 2
    I feel bad about this :( Works great with path instead PATH – userGuest Apr 24 '17 at 13:48
  • 3
    @userGuest You would not have figured it out (as quickly) if you hadn't asked, so don't feel bad. :-) – Kusalananda Apr 24 '17 at 13:49
  • 1
    @userGuest yes, you should get into the habit of never using UPPER CASE variable names in shell scripts. That way, you don't need to remember which are reserved words and which can be used. Also, if this answer solved your issue, please take a moment and accept it by clicking on the check mark to the left. That will mark the question as answered and is the way thanks are expressed on the Stack Exchange sites. – terdon Apr 24 '17 at 13:49
  • 1
    Of course, I have to wait one minute more :) – userGuest Apr 24 '17 at 13:51
  • 3
    While avoiding ALL_CAPS variables is a good idea (my preference is CamelCase, as no system-defined variables I've seen ever use it, and it saves me including underscores to make names easy to read), it's also good to use more meaningful variable names than just "path". I'll have $Source and $Dest or something like that. – Monty Harder Apr 24 '17 at 15:42
  • Avoiding uppercase for your private variables is not merely a matter of taste; uppercase is reserved for system use specifically so you can avoid clobbering system variables by mistake. – tripleee Apr 25 '17 at 05:28
  • 1
    @tripleee Added a qualifier to that statement. – Kusalananda Apr 25 '17 at 06:38
  • Lowercase $path is also a problem in csh, tcsh and zsh (when not in sh emulation) though (array counterpart of the $PATH scalar variable). Something to be aware of when writing scripts for those shells. – Stéphane Chazelas Apr 25 '17 at 07:36