Comment on mv *.jpg is complete bullshit.
GenderNeutralBro@lemmy.sdf.org 8 months agoAhhh. That’s a confusing thread, with a couple confounding factors.
The OP in that thread is attempting to a batch rename, which is out of scope of the mv command.
If you are NOT trying to change the name of the file, I recommend always making the last argument of mv your destination directory, rather than the destination file. This is strictly mandatory if you are moving multiple files.
OP in that SO thread used the filename as the destination path — a filename which did not exist, and therefore could not be resolved by the wildcard. And if it had existed, the move would have failed. Because of that, mv /data/*/Sample_*/logs/*_Data_time.err /data/*/Sample_*/logs/*_Data_time_orig.err is not a valid command.
OP cannot accomplish what they want with a single mv command. They would need to use a loop or something like find.
I agree that the lack of universal consistency in how commands handle arguments is unfortunate. There’s no way around that without reinventing the entire OS. Many commands let you pass ‘–’ as an argument to signify that any subsequent arguments should not be interpreted as options even if they begin with ‘-’. But that’s entirely up to the implementation of each program; it’s not a shell feature.
Future OS designers: consider typed arguments. Abandon all legacy cruft.
mindbleach@sh.itjust.works 8 months ago
Disagree. If wildcard expansion is not a feature of the tool, it shouldn’t be up to the tool to shape how each expanded input is passed. Some hideous escape syntax ought to force
*.jpgto appear as“-a.jpg”instead of-a.jpg, once it reachesmv.Instead
*is acting as a cheeky littlelsalternative, minus any degree of formatting control, and piping actuallsinput intomvis similarly fraught with complications.GenderNeutralBro@lemmy.sdf.org 8 months ago
The issue here is that there’s no difference here between
-a.jpgand“-a.jpg”.Go ahead and try these commands. They are 100% equivalent:
The reason these are equivalent is because quoting (and expansion, and globbing) is processed in the shell. The shell then passes the evaluated string as an argument to the tool. All of those evaluate to the same string, so they look exactly the same to the
lscommand.What is the solution if there’s a file name that matches something the tool thinks is an argument? What would the correct behavior be?
The only solution is to include some way to communicate to the tool what each argument is. In practice, you could do
ls – *and it would work even if the first filename was “-laR”. However, not all tools use the–convention. This is really core to the design of the OS, in that command arguments have no type.mindbleach@sh.itjust.works 8 months ago
Jesus. That’s beyond Javascript levels of “helpfully” reinterpreting strings. That’s borderline Excel behavior.
What is the point of strings allowing every character besides
\0if they’re gonna eat quotation marks?NeatNit@discuss.tchncs.de 8 months ago
All I can tell you is that, in my opinion, it’s ridiculous and terrible that old-school terminals haven’t been replaced yet with something more user-friendly and self-explanatory, at least in the same-machine user space. But given that they are what they are, some basic understanding of what shells do is required in order to use them, and you don’t have that understanding (I don’t fault you for this).
The key point here is that programs/commands always receive an array of string arguments, and it’s the shell’s job to translate your command line into that. Quoting (like in
-m=“my message”), shell variables (like$HOME) and various other things are processed by the shell and not the program, and the expectation is that the user knows this. So quotes are never visible to programs, and the upside is that programs never need to process such quotes - making these features universal without having various random bugs in each program’s implementation.