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.

CodePudding user response：

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.

CodePudding user response：

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.

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 executing rm -rf /usr/local/bin when you really meant rm -rf /usr/local/bin/*, or perhaps the machine just came that way.