1

I know that to deal with spaces in file names you should wrap the entire file name between quotes but this is not working for this script, indeed what is happening is the exact opposite, it only works without using quotes and I don't understand why. Tested with gnome-terminal.

echo "Drag and drop some file"
read FILE
NAME=$(basename "$FILE")
cp "$FILE" ~/foo/bar/"$NAME" && echo "Success!"
Wieland
  • 6,353
  • 3
  • 28
  • 31
  • What, exactly, do you enter as $FILE? The only suggestion I can make to this code is to `read -r FILE` – glenn jackman Sep 13 '22 at 01:14
  • You say "it only works without using quotes", but you have quotes in all the right places (where you're trying to get the value inside the `FILE` variable). Were you trying to put quotes around the FILE variable name in the `read FILE` line or the NAME variable name in `NAME=$(basename ...)`? – Sotto Voce Sep 13 '22 at 01:33
  • 1
    "What, exactly, do you enter as $FILE?": if I type ```my file.txt``` it works but ```"my file.txt"``` or ```'my file.txt'``` doesn't –  Sep 13 '22 at 01:45
  • What's your actual question? Your script works in GNU bash, version 5.1.16, if you just remove the extraneous backticks. – appas Sep 13 '22 at 01:50
  • "but you have quotes in all the right places": The drag and drop function adds single quotes, it's about these quotes that I'm referring, as explained in this answer: https://stackoverflow.com/a/32060406 –  Sep 13 '22 at 01:51
  • "What's your actual question?": I'm using bash 5.0.3 and its not working with file names with spaces –  Sep 13 '22 at 01:57
  • When you **enter** the name, don't use quotes. Those will be treated as literal characters, so your script won't be able to find the file. The quotes _in the script_ will be removed by the shell at the appropriate time, but any characters entered by the user are not handled specially by the shell. – glenn jackman Sep 13 '22 at 03:00
  • "When you enter the name, don't use quotes": Thanks, it works! but this is not the expected behavior, it doesn't make sense... –  Sep 13 '22 at 03:15
  • For those who still don't understand my question: Typing ```/home/foo/abc 123.txt``` is not supposed to work (because of the space between "abc" and "123"), but works, while typing ```"/home/foo/abc 123.txt"``` which is supposed to work, doesn't. Dragging and dropping the file into the terminal window instead of typing (as suggested by the script) doesn't work either (because gnome-terminal automatically wraps the path within single-quotes, as stated in the following answer: https://stackoverflow.com/a/32060406 ). –  Sep 13 '22 at 03:15
  • "but this is not the expected behavior, it doesn't make sense" – It's not expected by you, but [it's expected by `read`](https://unix.stackexchange.com/a/209184/108618) you used. The fact `gnome-terminal` adds quotes does not mean all tools expect this. The [answer you linked to](https://stackoverflow.com/a/32060406) uses some code to parse data coming from `gnome-terminal`; your snippet does not. Your belief about what is or is not supposed to work does not match what actually works. "How is it possible that this doesn't work?" – "Protocol" mismatch. – Kamil Maciorowski Sep 13 '22 at 06:42
  • Can you confirm that when you say "wrapping the filename in quotes", you're talking about when you input the filename using `read`? So that the name of a file called `my file` is entered as `'my file'` or `"my file"`? – Kusalananda Sep 13 '22 at 09:05
  • Yes @Kusalananda exactly –  Sep 14 '22 at 22:08

1 Answers1

1

Hopefully an example will illustrate the difference: the stuff between the single quotes is like what you enter at the read command

Entering a name without quotes:

f='file 1'
touch "$f"
ls --literal -l "$f"

-rw-r--r-- 1 glennj glennj 0 Sep 13 01:57 file 1

Entering a name with quotes:

f='"file 2"'
touch "$f"
ls --literal -l "$f"

-rw-r--r-- 1 glennj glennj 0 Sep 13 01:57 "file 2"

The double quotes are literal characters in this case: they are actually part of the filename.

When you use quotes in what you enter at read, the quotes are literally part of the text.

glenn jackman
  • 84,176
  • 15
  • 116
  • 168