I was following the SocketXP Agent Download & Setup, and on the very first step I am asked to run the following command:
curl -O https://portal.socketxp.com/download/linux/socketxp && chmod +wx socketxp && sudo mv socketxp /usr/local/bin
This was followed by some confusion, becuase the bin
-folder now appeared to be an executable. It turns out that rather than inserting socketxp
into the /usr/local/bin
folder, I actually deleted the whole folder and replaced it with the socketxp
file, now renamed to a file called bin
.
However, after recreating the folder, I see I can transfer test files into it without issues with
~touch test
~sudo mv test /usr/local/bin
So after seeing this, I re-ran the same socketxp
installation command, and this time around it worked fine.
I’m at a loss as to what the original problem was, but I am very interested in not having this happen again. I suspect I am missing some basic mv
knowledge. Grateful for any tips and pointers that can explain for me what caused the issue
I was doing this on a 64-bit Linux SIMATIC controller from Siemens, which runs an OS based on Debian.
2
Answers
In Linux you can use
mv
also to rename files. To prevent a mistake like yours, always add a / at the end of a path that you want to move something into:sudo mv test /usr/local/bin/
This would have behaved as you expected and put the file test into the folder /usr/local/bin.
As @JohnBollinger stated, the behaviour to expect would be that
mv
moves files into an existing folder if you do not explicitly tell it that the last parameter is NOT a directory.In your case it could have been that /usr/local/bin simply didn’t exist when you executed your command. In this case the variant with the appended / would have emitted an error message. Or you accidentally specified the option -T (maybe intended for some other command or a copy-paste-mistake?)
Not plausible. When the destination path in a
mv
command is a directory, the source file(s) are moved into that directory (unless that is overridden by a command-line option). This is consistent with what you observed in subsequent experiments.However, if only one source is given and the destination path either does not exist (but its parent directory does) or designates a regular file, then
mv
renames the source to the destination. We can only guess about what actually happened, but my first guess would be that/usr/local/bin
did not initially exist. That might have arisen because of an earlier error, such as executingrm -rf /usr/local/bin
when you really meantrm -rf /usr/local/bin/*
, or perhaps the machine just came that way.