Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #29291 > unrolled thread

RE: Moving folders with content

Back to article view | Back to comp.lang.python

Contents

  RE: Moving folders with content <jyoung79@kc.rr.com> - 2012-09-16 08:02 +0000
    Re: Moving folders with content Hans Mulder <hansmu@xs4all.nl> - 2012-09-16 12:40 +0200
      Re: Moving folders with content Nobody <nobody@nowhere.com> - 2012-09-16 15:31 +0100
        Re: Moving folders with content Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-16 14:53 -0400
        Re: Moving folders with content Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-16 16:53 -0400

#29291 — RE: Moving folders with content

Thank you  "Nobody" and Hans!

> You may want to use the subprocess module to run 'ditto'.  If
> the destination folder does not exist, then ditto will copy MacOS
> specific aspects such as resource forks, ACLs and HFS meta-data.

This looks like a good direction to go.  Maybe something like:

>>> import os
>>> import subprocess
>>> 
>>> p1 = os.path.expanduser('~/Desktop/IN/Test/')
>>> p2 = os.path.expanduser('~/Desktop/OUT/Test/')
>>> 
>>> cmd = 'ditto -vV "' + p1 + '" "' + p2 + '"'
>>> 
>>> v = subprocess.check_output(cmd, shell=True)
>>> Copying /Users/jay/Desktop/IN/Test/ 
copying file ./.DS_Store ... 
6148 bytes for ./.DS_Store
copying file ./dude.txt ... 
4 bytes for ./dude.txt
copying file ./new.png ... 
114469 bytes for ./new.png

Jay

[toc] | [next] | [standalone]

#29299

On 16/09/12 10:02:09, jyoung79@kc.rr.com wrote:
> Thank you  "Nobody" and Hans!

You're welcome!

>> You may want to use the subprocess module to run 'ditto'.  If
>> the destination folder does not exist, then ditto will copy MacOS
>> specific aspects such as resource forks, ACLs and HFS meta-data.
> 
> This looks like a good direction to go.  Maybe something like:
> 
>>>> import os
>>>> import subprocess
>>>>
>>>> p1 = os.path.expanduser('~/Desktop/IN/Test/')
>>>> p2 = os.path.expanduser('~/Desktop/OUT/Test/')
>>>>
>>>> cmd = 'ditto -vV "' + p1 + '" "' + p2 + '"'
>>>>
>>>> v = subprocess.check_output(cmd, shell=True)

This looks iffy: it would break if there would be any double
quotes in p1 or p2.  You might think that os.path.expanduser
would never expand '~' to something containing a double quote,
but you'd be wrong:

>>> import os
>>> os.environ['HOME'] = 'gotcha!"; rm -rf '
>>> print(os.path.expanduser('~/Desktop/IN/Test/'))
gotcha!"; rm -rf /Desktop/IN/Test/

It's easy and safer to avoid using 'shell=True' option:

cmd = ['ditto', '-vV', p1, p2]
v = subprocess.check_output(cmd, shell=False)

In this case, the safer version also happens to be shorter and
more readable.  But you should get into the habit of using
shell=False whenever possible, because it is much easier to
get it right.


Hope this helps,

-- HansM

[toc] | [prev] | [next] | [standalone]

#29313

On Sun, 16 Sep 2012 12:40:18 +0200, Hans Mulder wrote:

> But you should get into the habit of using shell=False whenever
> possible, because it is much easier to get it right.

More accurately, you should get into the habit of passing a list as the
first argument, rather than a string.

On Unix-like systems (including Mac OS X), this effectively requires
shell=False. Passing a list with shell=True has behaviour which is
well-defined, but rarely useful (the first element of the list will be
executed as a shell command, the remaining elements will be available via
the shell variables $1, $2, etc within that command).

On Windows, the list is converted to a command string using the same
quoting rules regardless of the value of the shell= parameter. The
difference is that shell=False requires the "executable" to actually be a
binary executable, while shell=True allows it to be some other type of
file (e.g. a batch file, Python script, etc).

[toc] | [prev] | [next] | [standalone]

#29342

On Sun, 16 Sep 2012 15:31:07 +0100, Nobody <nobody@nowhere.com>
declaimed the following in gmane.comp.python.general:


> difference is that shell=False requires the "executable" to actually be a
> binary executable, while shell=True allows it to be some other type of
> file (e.g. a batch file, Python script, etc).

	While it is true that "programs" that require an interpreter to be
present won't run directly, the main difference is that "shell=True"
allows for use of the built-ins -- commands like DIR, COPY, DEL...

	One can always preface the others with the interpreter program name
(granted, in the case of "BAT" files, that interpreter IS the command
shell, so it if rather perverse to say "run this file in this shell"
while saying "don't use a shell" <G>).


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#29350

On Sun, 16 Sep 2012 14:53:02 -0400, Dennis Lee Bieber
<wlfraed@ix.netcom.com> declaimed the following in
gmane.comp.python.general:

> On Sun, 16 Sep 2012 15:31:07 +0100, Nobody <nobody@nowhere.com>
> declaimed the following in gmane.comp.python.general:
> 
> 
> > difference is that shell=False requires the "executable" to actually be a
> > binary executable, while shell=True allows it to be some other type of
> > file (e.g. a batch file, Python script, etc).
> 
> 	While it is true that "programs" that require an interpreter to be
> present won't run directly, the main difference is that "shell=True"
> allows for use of the built-ins -- commands like DIR, COPY, DEL...
> 
> 	One can always preface the others with the interpreter program name
> (granted, in the case of "BAT" files, that interpreter IS the command
> shell, so it is rather perverse to say "run this file in this shell"
> while saying "don't use a shell" <G>).

	I may have over trimmed the quote -- the preceding comment applies
to usage on M$ Windows... (with one typo corrected)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web