2

GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
Ubuntu 20.04.3 LTS

So, I downloaded like 20 7z files and I wanted to move them somewhere, but NOT the previous 7z files I already had in Downloads. (The filenames had some spaces in them, too, btw.) So I did like

mv `find -mmin -700 -iname "*.7z" -printf "\"%f\" "` ~/FOLDER/

which should have found all 7z files modified in the last ~11 hrs or so, and moved them to ~/FOLDER/.

Instead of moving all the files, it gives me a heap of errors with fragments of the filenames, like

mv: cannot stat 'Pinball': No such file or directory

I've tried the find command on its own, and it gives me a reasonable-looking list of files, each surrounded by quotes, all on one line. I ALSO tried pasting the output of the find command into mv PASTED_HERE ~/FOLDER/, like I thought the backticks basically DID, and it worked fine. (I also tried $() instead of the backticks, but I got the same errors as with the backticks.) What's going wrong?

Erhannis
  • 229
  • 1
    mv $(find …) … (or equivalent with backticks) is basically as flawed as for f in $(find …); do …, the Bash pitfall number 1. – Kamil Maciorowski Jan 03 '22 at 18:55
  • "Backticks giving different result than pasting result" -- yes, because they're a different thing. Pasting the output on the command line has it go through all of the shell's command line processing, including parsing shell operators, quotes and expansions. Those are not done on the output of expansions, and it's very well so, since otherwise it would be impossible to handle e.g. filenames that contain quotes or something that looks like shell operators. That's also the same as happens in e.g. Perl or any other programming language when e.g. the value of a variable is used. – ilkkachu Jan 03 '22 at 19:20
  • @ilkkachu I see now that they are different things, yes. I'm still not convinced they SHOULD be, but that's sortof irrelevant, I guess. I'm not sure why you bring up "the output of expansions", and FTR it appears that the result of command substitutions are expanded. – Erhannis Jan 03 '22 at 19:37
  • @KamilMaciorowski I think this was my primary problem. I expected command substitution to substitute the result back into the original command, and interpret it as though you had typed it there to begin with. Instead it (AFAICT) takes the result, and ONLY considers spaces and glob characters as "special" (notably ignoring quotes). While I really want to go on an angry rant about this, it probably wouldn't accomplish anything. So, thanks for the enlightenment. – Erhannis Jan 03 '22 at 19:41
  • Since roaima's answer at least gives a functional solution to the problem I was trying to solve, I'll leave this open for a few hours in case anybody has any more wisdom to shed, then otherwise accept roaima's answer. – Erhannis Jan 03 '22 at 19:43
  • @Erhannis, hmm, command substitutions are a form of expansion, and the same rules apply. If you have the string Don't_stop_me_now.mp3 in the variable f, then running something like ls $f doesn't go on to process the single quote as a quote character. If it did, it would be impossible to work with arbitrary filenames in the general case, as a filename could also contain double quotes and spaces... – ilkkachu Jan 03 '22 at 19:44
  • 1
    @Erhannis, yes, that's how the POSIX shell works. Unquoted expansions are subject to word splitting and globbing, both of which you should usually avoid by quoting the expansion. Or by switching to zsh or some real programming language and using NUL-separated lists of filenames instead of quotes or newline-terminators. No, not all of us love how it is, but that's what a history of keeping compatibility with the past gives you. – ilkkachu Jan 03 '22 at 19:49
  • @ilkkachu (note, this was in response to the "Don't_stop_me_now" comment, we posted at the same-ish time) I base my "command substitutions are expanded" on experimental evidence: if I type echo *.txt into the console, I get *.txt, but if I type ls $(echo *.txt) into the console, I get a list of filenames. (Based on the rest of the discussion here, I wouldn't expect it to behave properly with e.g. filenames-with-spaces, but it does seem to be expanded, at least.) Is this consistent with what you were saying? – Erhannis Jan 03 '22 at 19:49
  • @Erhannis, I'm not sure what you mean with "command substitutions are expanded". If you did rm $(cat files.txt), then yes, the shell would expand the command substitution by running the command inside, removing any trailing newlines, word splitting and globbing the result and passing the resulting fields as arguments to rm. But it wouldn't process any quotes on the output. It also wouldn't process any quotes on the result of the *.txt glob. – ilkkachu Jan 03 '22 at 19:52
  • And no, ls $(echo *.txt) wouldn't work if the glob gave any filenames with whitespace (or something like *.txt which itself is a valid filename...). And that's exactly because the result of $(echo ...) is word-split, while the plain glob *.txt as such isn't. – ilkkachu Jan 03 '22 at 19:54
  • @ilkkachu No quotes, yes, just everything else. :P Anyway, I think we're on the same page now. And thank you for acknowledging that the-way-things-are is largely due to the-way-things-were, not simply the-way-things-should-be. So, does zsh behave differently than bash does, then? – Erhannis Jan 03 '22 at 19:55
  • See also Why does my shell script choke on whitespace or other special characters?, When is double-quoting necessary?, http://mywiki.wooledge.org/WordSplitting – ilkkachu Jan 03 '22 at 19:55
  • 1
    @Erhannis, not everything else, notably it also doesn't process expansions and operators. You could have a file called "hello $(bad command) && echo foo", and it would work fine with rm ./*, or indeed if the name was contained in a variable, and you did rm "$filename". Zsh doesn't do word splitting on variables by default, (err, but I think it does on command substitutions, for some reason) and it has better tools on controlling it too, and for using the output of e.g. find -print0. – ilkkachu Jan 03 '22 at 19:58

1 Answers1

3

The quotes are not part of the filenames, so you cannot include them in the names and expect it to work.

find -mmin -700 -iname '*.7z' -exec echo mv -v {} ~/FOLDER/ \;

Or (with GNU mv),

find -mmin -700 -iname '*.7z' -exec echo mv -vt ~/FOLDER/ {} +

In either case, remove echo when you're happy with the proposed result.

As a side comment, backticks are no longer considered best practice. Instead of ` ... ` use $( ... ), possibly double-quoted if you need the result to be treated as a single word.

ilkkachu
  • 138,973
Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • So, #1, while this solves my problem, it doesn't answer my question - I still don't know why the backticks (nor $()) aren't working. I include quotes in my filenames all the time, when the filenames contain spaces; why wouldn't it work in a command substitution? – Erhannis Jan 03 '22 at 18:55
  • And #2, there's something I'm missing, because your solution DOES work, but looks like it SHOULDN'T. With echos, I get like mv -v ./This is a filename.7z /home/USERNAME/FOLDER/, which isn't a command that actually works if you just type it in - you need the quotes to get one filename-with-spaces rather than three filenames. Why does it work? – Erhannis Jan 03 '22 at 18:55
  • 1
    #2 the shell needs quotes on the command line to know how (not to) split words. So for mv 'one word' 'item' the quotes around one word tell the shell it's a single item of eight characters (including a space). The find substitution for {} avoids using the shell to tokenise the line so you don't need quotes to keep filenames with spaces intact. The echo shows what's being handled, not a copyable command line – Chris Davies Jan 03 '22 at 19:03
  • #1 the quotes aren't part of the filenames and so must not be included in the expansions used by mv – Chris Davies Jan 03 '22 at 19:04
  • Take a read of Why does my shell script choke on whitespace or other special characters? for more details – Chris Davies Jan 03 '22 at 19:06