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

mv T353* $PATH #this is the line 16

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

  • 13
    Mangling $PATH is probably not a good plan – Jeff Schaller Apr 24 '17 at 13:39
  • @Jeff Schaller, probably? it's not a good plan at all and for sure to use $PATH instead of $PWD. – Slyx Apr 25 '17 at 1:00

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.

  • 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

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.