cp: missing destination file operand after [duplicate]
Asked Answered
H

5

7

Im trying to do a full back up and copy over all files from one directory into another directory

    #!/bin/bash 

    #getting files from this directory
    PROJECTDIRECTORY=/../../Project3 

    #Copied to this directory 
    FILEBACKUPLOCATION= /../.../FMonday

    for FILENAME in $PROJECTDIRECTORY/*
    do
        cp $FILENAME $FILEBACKUPLOCATION
        done  

But I keep getting this error

./fullbackup: line 6: /../../FMonday: Is a directory
cp: missing destination file operand after
Haycock answered 2/12, 2013 at 8:45 Comment(4)
Did you try without the space after the equal sign: FILEBACKUPLOCATION=/../.../FMondayDuodenary
Isn't /../../Project3 the same thing as /Project3? Also, ... is misleading. Anyway, add slash at the end of destination path.Isotone
It's also wise to double-quote the variables to avoid errors caused by issues such as space characters in the path.Desrosiers
I think it is calling for possible mistakes to name a directory ... Note that ... has a special meaning in some contexts (Novel NetWare, Windows 95, Golang). --- Using double quotes around variable references will also better show that the variable is either empty or nonexistent and it will better handle possible errors in such cases (typical example which can overwrite files: cp path/* $nonexistent_var).Underwater
H
8

Variable assignments in bash scripts require no space between the variable name and value or (unless quoted) within the value. Since a space was present in the line FILEBACKUPLOCATION= /../.../FMonday, it attempted to execute /../.../FMonday as a command (which caused the first error) with FILEBACKUPLOCATION assigned to an empty string. The variable was then not assigned when the other command further down tried to use it (accounting for the second error).

Haycock answered 2/12, 2013 at 16:59 Comment(0)
P
2

I think this is what you need is FILEBACKUPLOCATION=/FMonday/

Petes answered 2/12, 2013 at 8:58 Comment(0)
D
0

In my case, I just used used space and dot operator after the file name. It worked perfectly.

For Example, darthVader is a file name which is inside F drive. So, I used the command "mv /f/darthVader . "

Disappoint answered 13/5, 2018 at 11:35 Comment(0)
R
0

Has you already found the variable needs to be FILEBACKUPLOCATION=/location with no space, also if possible try to make your script a little more portable by using something like:

FILEBACKUPLOCATION=$HOME/backup/FMonday

In this case, the location is relative to your user $HOME environment variable.

Going further, if you want to keep 2 files in sync probably you could do better with rsync one of the advantages is that it will only copy the files that don't exist or update the ones that have been changed.

You indeed could create an alias to copy/sync files on demand, for example:

alias cpr="rsync --delete --archive --numeric-ids --human-readable --no-compress --whole-file --verbose --info=progress2"

Then if you would like to sync contents of /dir/foo into /dir/bar, could simply do:

$ cpr /dir/foo/ /dir/bar/

Your script also could then be something like:

#!/bin/sh

ORIGIN=/path/to/foo/
DESTINATION=/path/to/bar/

rsync --delete \
--archive \
--numeric-ids \
--human-readable \
--no-compress \
--whole-file \
--verbose \
--info=progress2 \
$ORIGIN $DESTINATION

Notice that in this case the options --no-compress and --whole-file are used, mainly because the files will be copied locally, if this where a remote server options could be different, check this post (The fastest remote directory rsync over ssh archival I can muster (40MB/s over 1gb NICs)

Roaster answered 18/8, 2018 at 19:50 Comment(0)
P
-1

By the way, I was running into the same error myself. Mine turned out to be caused by misspecifying the pattern of files I wanted to be copied from the directory (meaning that the files in the directory didn't match to the pattern I specified previously). Once I fixed the pattern and the files matched the pattern, my problem was gone.

Considering the problem I have had, the error is very misleading, FYI.

Plaster answered 1/7, 2024 at 8:27 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.