Mount expression not working in nautilus script
 

I'm sure this is something really stupid but I'm really tired and I'm kind of burned out on ideas, at this point.

Here is a segment from a script (the script is complicated so I'll just post the problem)

For debugging, I have the first line that echoes back the command being run (so I can find obvious syntax errors) and the second line runs the command.

The first line returns:
If this line is cut and pasted into a bash shell it runs and the mount occurs fine.

However, this is being run in a nautilus script and the output of the same mount command is the syntax for mount???

I have really no idea why a command run by bash would work and the same command run by nautilus would fail?

Hi,

Only thing I see is a missing fstype option. Maybe when you do this from a bash shell it is guessed correctly and not so when done from a nautilus script (which I'm not familiar with).

Try changing it to: Hope this helps.

Yea, I originally started out defining the iso9660 type and when mount spit back the syntax I figured I'd widdle the mount command down to the fewest possible options to reduce the debugging surface area. There's something deeper going on here because all the variations of the command work when typed into the shell directly but when run in nautilus mount just spits out syntax and ignores the parameters.

Thanks!

In my expirence the scripts does not handle very well spaces in file names

Is it possible for you to change the iso filename and to mount it to another directory?

Thanks for the suggestion. Actually the mount point is derived from the $(basename) of the ISO so changing the name would also change the mount point.

Right now I'm trying to troubleshoot with a file on the local system but no, all the ISOs are all on a network share and the environment is a shared small business Windows server. The users can't comprehend the concept that spaces could be a problem (and I'm trying to demonstrate that Linux can be a realistic option for this organization).

I've escaped all the spaces with sed and when the command is run in the shell directly, all is well so there must be something unique to Nautilus causing this problem.

Looks like I'm gonna have to come up with something in python or C if I can't resolve soon.

Can you please post how you escaped the white-space?

The following works for a single ISO file that does not have white-space in the filename:
And to clean up:
I placed these scripts in ~/.gnome2/nautilus-scripts.

P.S. Obviously the scripts are missing code for error checking.

I do appreciate the response but this is unrelated to the actual problem I'm trying to solve. As mentioned in the original post, this command:

When run in the bash shell directly works but when its run via a nautilus script it doesn't. The reason I'm absolutely sure that this is the command being run is because I added a debugging line just above this call to record the command being run (just to be absolutely certain; since clearly mount wouldn't be spitting out syntax unless there was a syntactical error.)

Thanks for sharing! But yea, the segment of code I'm debugging works fine for files without spaces so at this point I think there may be a bug in Nautilus or some developer secret that I'm not aware of that will allow escaped paths to work. As mentioned previously, this is a proof of concept for a customer considering linux implementation and renaming existing shared files is not an option.

Your latter command is wrong. It should be
If you actually have somehow generated $eFile and $eMount with shell-special characters escaped with backslashes (which honestly I do not believe you have), don't. Use proper quoting instead.

If you quote the variables like I have, above, the variables may contain any characters that are valid in pathnames (i.e. anything except NULs or zero bytes), and the command will work. (It is possible sudo won't work, depending on your configuration, if you've redirected standard input and/or standard output, but that'd show up as a sudo error anyway.)

I work with files with all kinds of weird stuff in their names; sometimes with things that won't show up properly anywhere (like both UTF-8 and CP-1252 latin characters in the same file name). I can attest that if you always use double quotes with variable references, Bash scripts and Linux filesystem commands can handle any file name you can create. (The only exception I know of is when you must provide the file name in a string that is interpreted by a shell first. That case is solved by double-quoting the file name within the string, with a backslash added before ! " $ ` \ characters.)

Ugh...

So I did finally solve the mystery and it was all on me. The escaping/quoting was not the issue at all. It turned out that my call to the environmental variable $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS[0] resulted in a null terminator \0 character being sent to mount, following the first element (which mount didn't understand). This null terminator was not showing up in gEdit when echoing the command to execute to a file so this resulted in me being able to copy and paste from that file into the shell and the command getting executed successfully.

Thanks again everyone!