Nemo Actions simply unable to handle spaces in filenames

Bug #1330225 reported by Kiers
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linux Mint
Fix Released
Undecided
Unassigned

Bug Description

On Mint 17 (Cinnamon, 32 bit, i386) Nemo Actions %F field simply is incapable of handling filenames\ with\ spaces!

I am trying to use with pdftk to merge two pdfs via single mouse click w Nemo Actions. A common enough use case.

My Exec field calls a local wrapper bash script to convert the %F filename array (which Nemo presents with plain spaces in filenames and not escaped (ie w backslash "\") in manner in which pdftk (or any linux command) would like it).

eg actions file
Exec=./wrapper.sh %F
selection=m
extensions=pdf;

eg. wrapper.sh:
#!/bin/bash
IFS=$(echo -e "\t") # to delineate variables by unique "tab" char rather #than mere spaces which confuses shell
echo "$@" #for debug purposes
FILES=$(echo "$@" | sed -e 's:[^ ]*:&\\:g' -e 's:.pdf\\:.pdf:g' -e 's: /: /:g') #clean up %F variable passed to shell script with "\
# and tabs between filename arguments to ease separation
echo $FILES #debug purposes
pdftk $FILES cat output combinedfiles.pdf

The above converts the filename array passed by %F to a properly backslashed filename separated by tabs between filenames, and tells shell to expect tabs as a argument separator (via IFS).

But pdftk still is unable to process the argument passed in.

Apparently the problem is MUCH deeper.

For eg, Running wrapper.sh with trial arguments from command line:
./wrapper.sh ~/.local/share/nemo/actions/Nigeria Article.pdf ~/.local/share/nemo/actions/Putin Article.pdf
(note, this is the exact SAME variable string which is generated by "%F" by actions)

the aboveproduces the following output and ensuing errors on terminal:

/home/kiers/.local/share/nemo/actions/Nigeria Article.pdf /home/kiers/.local/share/nemo/actions/Putin Article.pdf
/home/kiers/.local/share/nemo/actions/Nigeria\ Article.pdf /home/kiers/.local/share/nemo/actions/Putin\ Article.pdf
Error: Unable to find file.
Error: Failed to open PDF file:
   /home/kiers/.local/share/nemo/actions/Nigeria\ Article.pdf
Error: Unable to find file.
Error: Failed to open PDF file:
   /home/kiers/.local/share/nemo/actions/Putin\ Article.pdf
Errors encountered. No output created.
Done. Input errors, so no output created.

However, please note the above paths to "Nigeria Article.pdf" and "Putin Article.pdf" are indeed valid and the files are there but pdftk is simply unable to handle the passed in arguments as the errors show.

It appears the passing of variables between nemo and the command line has some type of bug in it

It is TOO LATE in the evolution in Linux to still expect people NOT HAVING SPACES IN THEIR FILENAMES and integrated functionality in Mint 17 (LTS), such as NEMO ACTIONS, being simply UNABLE TO PROCESS TYPICAL FILENAMES.

Revision history for this message
Michael Webster (miketwebster) wrote :

No need to be dramatic about it, thanks for the report.

Revision history for this message
Michael Webster (miketwebster) wrote :

Try adding:

Quote=double

To your action. This will add quotes to each individual file path, and your argument vector will be valid.

Revision history for this message
Kiers (kalm77) wrote :

Sorry, Michael, no drama intended!

Yes, did try
Quotes=double
also tried
Separator=, (also whilst changing my variable IFS=, in the shell script to match).....Nemo does the right thing by placing the comma there (verified), but something gets lost in translation in handoff to shell. Thanx.

Revision history for this message
Michael Webster (miketwebster) wrote :

What I think I'll do is add another option to output space-escaped file names.

From our trial and error when developing actions, we had come to the conclusion the safest/most flexible way of handling filenames was to enclose them in quotes (And I've read a couple 'authoritative' postings on the matter as well - all, of course, come with a caveat that there are always exceptions).

The basic problem I think is that spaces aren't considered special, and are not considered standard escaped characters.

So, no matter what, if you use (with the double quotes):

"/home/mtwebster/foo\ bar/more\ foo/test.py"

the escape characters do not get absorbed, and you have an invalid path there. The same goes with single quotes (which is supposed to behave this way anyhow).

I don't want to change the default behavior at this point, because it'll force us to change all our existing actions in Nemo and other packages, as well as break anyone's personal actions that may be impacted (possibly without obvious evidence).

It's trivial to add the option though, I'll add it ASAP so hopefully it gets included in an update for 2.2.

Revision history for this message
Kiers (kalm77) wrote :

Many thanks. I think that one sentence: "spaces aren't considered special, and are not considered standard escaped characters" encapsulates the "weirdness" (outside my ability to even describe) i was seeing in outputs! relieved.

description: updated
Revision history for this message
Michael Webster (miketwebster) wrote :
Changed in linuxmint:
status: New → Fix Committed
Revision history for this message
Rik Shaw (rik-shaw) wrote :

I think that "Quote=double" works fine for our nemo actions. Note from #3 that it said "Quotes=double". It is Quote not Quotes. So, not sure why the "EscapeSpaces" is needed. In our testing with "Quote=double" it works for files with SPACES in name and ALSO for multiple files.

Revision history for this message
Kiers (kalm77) wrote :

@Rik: the typo 'quotes' is only in my verbal response here. the action file is correct.

Revision history for this message
Vlad Orlov (monsta) wrote :
Changed in linuxmint:
status: Fix Committed → Fix Released
Revision history for this message
Roadowl (roadowl) wrote :

Also, apparently at least some keywords handle their values in a case SENSITIVE manner.
Why? Your guess is as good as mine.

E.g. Quote=Double does NOT work where it would be expected; Quote=double DOES.
Just saying.

Revision history for this message
Michael Webster (miketwebster) wrote :

Yes, it's case sensitive. The sample.nemo_action (https://github.com/linuxmint/nemo/blob/master/files/usr/share/nemo/actions/sample.nemo_action) file lists all keywords in lowercase. This is what is expected.

Why? Why not? Linux is case sensitive as a rule. There aren't any mysteries here - use the rules and guidelines provided and it works.

Revision history for this message
cptX (myrbourfake) wrote :

In Linux Mint 21.1 (2023) in nemo 5.6.4 I can verify that this bug still exists!!

Steps to reproduce:

Create an action with the following content:

[Nemo Action]
Active=true
Name=Test
Comment=Test
Exec=<test.sh "%F">
Icon-Name=gnome-mime-application-x-compress
Selection=notnone
Extensions=any;
Quote=double

then in test.sh put the following content:

#!/bin/bash
echo ">>> $1" >/dev/pts/0;

then run nemo from terminal like this:

1. quit all nemo instances nemo -q
2. NEMO_ACTION_VERBOSE=1 nemo

then right click on a filename with space and select the action. You will see in terminal that the path doesn't include the space and shows only the part of the path before the space... Really frustrating and limiting !!!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.