skip to Main Content

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


  1. 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?)

    Login or Signup to reply.
  2. 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.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search