Support whitespace in filename (ubuntu 10.04)

[vinitkumar]

From paal.nil...@gmail.com on June 30, 2010 18:35:28

What steps will reproduce the problem? 1. Create a file with one or more spaces in its name.

2. Try to 'google picasa create file\ name.png' and it works
3. Try to 'google picasa create $(find /path -type f -name file*|sed 's\ \ _g') and it doesn't work. What is the expected output? What do you see instead? Expected to upload, instead it prints the file path up to the first whitespace in the filename.

Example of output from 2.: $ google picasa create ~/Pictures/nexus\ one\ 32x32.png Please specify title: test Loading file /home/paal/Pictures/nexus one 32x32.png to album test

Example of output from 3.: $ google picasa create $(find ~/Pictures/ -type f -name nexus*|sed 's\ \ _g') Please specify title: test Loading file /home/paal/Pictures/nexus\ to album test Traceback (most recent call last): File "/usr/bin/google", line 463, in main() File "/usr/bin/google", line 457, in main run_once(options, args) File "/usr/bin/google", line 356, in run_once task.run(client, options, args) File "/usr/lib/pymodules/python2.6/googlecl/picasa/service.py", line 299, in _run_create client.InsertPhotoList(album, photo_list=args, tags=options.tags) File "/usr/lib/pymodules/python2.6/googlecl/picasa/service.py", line 220, in insert_photo_list err.args[0].reason, AttributeError: 'int' object has no attribute 'reason' What version of the product are you using? On what operating system? What version of gdata-python-client (aka python-gdata)? Ubuntu 10.04, latest python-gdata (1.2.4-0ubuntu2), googlecl_0.9.7-1_all.deb. Please provide any additional information below. This may be more of a general linux question, but I would like to know if you have any suggestion on how to handle filenames with spaces.

Original issue: http://code.google.com/p/googlecl/issues/detail?id=196

[vinitkumar]

From tom.h.mi...@gmail.com on June 30, 2010 06:26:06

Could you apply the patch in issue 86 , or run the version of googlecl in the repository? It fixes the AttributeError you see, and you should get a meaningful error message.

[vinitkumar]

From ville...@gmail.com on July 05, 2010 01:14:54

Same issue with WinXP and GoogleCL 0.9.8 : filenames with whitespaces don't work. The error dump is shown below.

F:\manualbackups\backups\album\ellu>c:\google\googlecl\google picasa create --ti tle "Elina Collection 3" .jpg Loading file .jpg to album Elina Collection 3 Failed to upload *.jpg. (601: Found <type 'str'>, not path name or object with a .read() method)

[vinitkumar]

From tom.h.mi...@gmail.com on July 12, 2010 14:25:49

villejus, are you using Cygwin or some other shell that will expand the '*'? The windows command prompt does not usually do so.

Status: Feedback

[vinitkumar]

From asourdi...@gmail.com on August 10, 2010 08:48:06

Ugly workaround, if you're using a bash script:

title=$title google picasa create --title "$title" for i in *.jpg; do google picasa post --title "$title" $i done

[vinitkumar]

From bart...@gmail.com on October 16, 2010 01:38:44

Below is the patch which can potentially fix both cases mentioned in this issue. At least it worked for me with the following command lines:

1. Issue with find reported by paal.nilsen: google picasa create --title Test "$(find . -type f -name *.png)"
2. Issue with expansion of '' reported by villejus: google picasa create --title Test '.png'

I'd appreciate if you try it and report here if it works for you or not.

Ed

Attachment: Issue196.diff

[vinitkumar]

From tom.h.mi...@gmail.com on October 29, 2010 17:17:01

Thanks for addressing this issue, Ed.

I've committed a patch similar to Ed's that addresses the issue(s). Note that as mentioned, the correct syntax for the "find" expansion is "$(find /path -type f -name file*"

Expanding wildcards will work without putting them in quotes for both Unix and Windows. So for #2, Windows and Unix users have the same command: google picasa create "My Test Album" *.png

I've attached a patch against 0.9.11 that will fix this, and r489 in the trunk includes it already.

Status: Fixed

Attachment: enhanced_argument_expansion.patch

[vinitkumar]

From tom.h.mi...@gmail.com on October 31, 2010 12:13:20

Made a mistake in the above patch -- all that will do is print out the arguments that have been passed to google.py. Not terribly useful. Here's a fixed patch (and r490 is also fixed)

Attachment: enhanced_argument_expansion.patch