563579 - symbolstore.py still fails if the path to dump_syms contains a space

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I thought bug 492776 was supposed to have addressed all the spaces issues with symbolstore.py, but I just ran into a scenario where it fails.

I'm making a little package to send to Pierre to get symbols from his "10.4.11-but-symbols-don't-match" Mac (bug 563180), and in the process of testing, I expanded my archive a second time, so Mac OS X named the folder "macosx_symbols 2".  I was using . (and later `pwd`) as my output dir, quoting everything in the convenience script, but still getting output like:

[Qalaat-Samaan:~/Desktop/Downloads/macosx_symbols 2] smokey% ./ossymbols.sh
Breakpad symbols for Mac OS X 10_5_8
Preparing symbol storage directory

Generating OS symbols
sh: /Users/smokey/Desktop/Downloads/macosx_symbols: is a directory
sh: /Users/smokey/Desktop/Downloads/macosx_symbols: is a directory
sh: /Users/smokey/Desktop/Downloads/macosx_symbols: is a directory
…

If I renamed the directory to no longer have a space, all was well.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Actually, hmm.

I initially started writing an AppleScript (with the files all contained in the bundle, so it'd just be a double-click operation), and it would fail with the same error, even though I was using the Desktop as the output dir (and, of course, quoting and POSIX path-ing everything).

But my sh error was:

Breakpad symbols for Mac OS X 10_5_8
Preparing symbol storage directory

Generating OS symbols
sh: /Users/smokey/Desktop/Mac: No such file or directory
…

(the app was named "Mac OS X Symbols.app" and was located on the Desktop).  As before, renaming the bundle to not have spaces in its name fixed things.

So now I'm not so sure that symbolstore.py was the problem, or at least not the only problem (given the errors were different, "is a directory" vs "No such file or directory").

I really don't know ruby, so I think generate_macosx_symbols is well-quoted--except maybe for the File.join calls (not sure how those work)? http://mxr.mozilla.org/camino/source/tools/os-symbol-generation/generate_macosx_symbols#57

Comment 2

[Stuart Morgan]

Attachment: quote dump_syms path

If there's a space in the path to dump_syms, symbolstore.py chokes; this fixes that. I tried putting everything in a folder with a space and outputting to a folder with a space, and this made everything work in my tests.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 444345 [details] [diff] [review]
quote dump_syms path

Thanks for tracking this down, Stuart.  It works wonderfully in my AppleScript app (and doesn't seem to regress app-symbol-generation), but it has now broken my own convenience script (where everything lives in a no-spaces world), and it fails with the convenience script I was trying to make above, as well with direct invocation:

> [Qalaat-Samaan:dev/symbol-apps/macosx symbols] smokey%  ./generate_macosx_symbols ./symbolstore.py ./dump_syms ~/Desktop
> ^C./generate_macosx_symbols:62:in `readlines': Interrupt
> 	from ./generate_macosx_symbols:62

Oh, I figured out what's "wrong"; for whatever reason, this only works if your default shell is bash (mine is tcsh; I forget what AppleScript's 'do shell script' uses as its default shell, but I thought it was "user's default shell" since Troubleshoot Camino explicitly sets the shell to bash before exporting the NO_HACKS env variable).

If there's not a simple "fix" or you don't feel like tracking it down, explicitly setting the interpreter in the convenience script to /bin/bash does work; I'm only going to use a convenience script or the AppleScript app to do this, and anyone who is going to be running the full set of commands explicitly is 99.9999% likely to be on bash.

So r=ardissone either way; I just wanted to mention the issue.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(Although it does seem odd that this is the exact same fix made in bug 492776 on that line for the 'file' argument, which had no similar shell-specific fallout.)

Comment 5

[Stuart Morgan]

http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

Unfortunately, the scripts currently do some shell-interpreted calls. It would be nice to fix that, but it's not something I'm going to spend time on.

Comment 6

[Stuart Morgan]

Landed everywhere (2.0, CVS trunk, hg). I forgot the bug reference though :(

Comment 7

[Stuart Morgan]

(Except not really hg; I fail at hg)

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Really everywhere :) http://hg.mozilla.org/camino/rev/9b580987cb1f