The format of filename

[Neil Cerutti]

Where can I find documentation of what Python accepts as the
filename argument to the builtin function file?

As an example, I'm aware (through osmosis?) that I can use '/' as
a directory separator in filenames on both Unix and Dos. But
where is this documented?

 

[Leif K-Brooks]

Where can I find documentation of what Python accepts as the
filename argument to the builtin function file?

Python will accept whatever the OS accepts.

As an example, I'm aware (through osmosis?) that I can use '/' as
a directory separator in filenames on both Unix and Dos. But
where is this documented?

It's documented in the OS's documentation. It can be queried with os.sep
and os.altsep.

 

[Fredrik Lundh]

Where can I find documentation of what Python accepts as the
filename argument to the builtin function file?

As an example, I'm aware (through osmosis?) that I can use '/' as
a directory separator in filenames on both Unix and Dos. But
where is this documented?

in the documentation for your operating system. Python doesn't do
anything with the filenames.

</F>

 

[Neil Cerutti]

It's documented in the OS's documentation. It can be queried
with os.sep and os.altsep.

Thanks. The contents of 6.1.6 Miscellanious System Information
seems to be what I'm looking for.

 

[Neil Cerutti]

in the documentation for your operating system. Python doesn't
do anything with the filenames.

Is translation of '/' to '\\' a feature of Windows or Python?

 

[Leif K-Brooks]

Is translation of '/' to '\\' a feature of Windows or Python?

It's a feature of Windows, but it isn't a translation. Both slashes are
valid path separators on Windows; backslashes are just the canonical form.

 

[Neil Cerutti]

Is translation of '/' to '\\' a feature of Windows or Python?

Well, *that* was easy to discover on my own. ;-)

Thanks for the pointers.

 

[Fredrik Lundh]

Is translation of '/' to '\\' a feature of Windows or Python?

Windows. Random MSDN link:

http://msdn2.microsoft.com/en-us/library/77859s1t.aspx

Win32 operating systems support both the backslash (\) and
the forward slash (/). /.../ (However, the Windows operating
system command shell, CMD.EXE, does not support the forward
slash in commands entered at the command prompt.)

for general file naming guidelines for Windows (including the shell), see:

http://msdn.microsoft.com/library/en-us/fileio/fs/naming_a_file.asp

</F>

 

[Neil Cerutti]

Well, *that* was easy to discover on my own. ;-)

Thanks for the pointers.

Some experimentation shows that Python does seem to provide
*some* translation. Windows lets me use '/' as a path separator,
but not as the name of the root of a partition name. But perhaps
this a peculiarity of the commands themselves, and not of Windows
path names in particular.

C:\PYTHON24>CD /
The syntax of the command is incorrect.

C:\PYTHON24>CD \
C:\>EDIT /PYTHON24/README
The syntax of the command is incorrect.

 

[Tim Chase]

As an example, I'm aware (through osmosis?) that I can use '/' as

in the documentation for your operating system. Python doesn't do
anything with the filenames.

Windows seems to be (occasionally) doing the translation as /F
mentions:

C:\temp> python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information..... print line.strip()
....
1
2
3
C:\temp> REM try the same filename convention from dos prompt
C:\temp> type subdir/test.txt
The syntax of the command is incorrect.
C:\temp> REM try with quotes, just in case...
C:\temp> type "subdir/test.txt"
The syntax of the command is incorrect.
C:\temp> notepad subdir/test.txt
C:\temp> REM correctly opened the text file in notepad

Windows seems to doing the translation inconsistently (I know
that comes as a shock...)

-tkc

 

[Fredrik Lundh]

Windows seems to be (occasionally) doing the translation as /F
mentions:

as leif pointed out, there's no translation.

C:\temp> REM try the same filename convention from dos prompt
C:\temp> type subdir/test.txt
The syntax of the command is incorrect.
C:\temp> REM try with quotes, just in case...
C:\temp> type "subdir/test.txt"
The syntax of the command is incorrect.

"type" is built into the command shell. it's the command shell that
refuses to deal with forward slashes, not the underlying API:s.

Windows seems to doing the translation inconsistently (I know
that comes as a shock...)

it's a documented inconsistency, which is preserved mostly for
historical reasons (the shell syntax hasn't changed much since
the CP/M days)

</F>

 

[Steve Holden]

in the documentation for your operating system. Python doesn't do
anything with the filenames.

Windows seems to be (occasionally) doing the translation as /F
mentions:

C:\temp> python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information..... print line.strip()
....
1
2
3
C:\temp> REM try the same filename convention from dos prompt
C:\temp> type subdir/test.txt
The syntax of the command is incorrect.
C:\temp> REM try with quotes, just in case...
C:\temp> type "subdir/test.txt"
The syntax of the command is incorrect.
C:\temp> notepad subdir/test.txt
C:\temp> REM correctly opened the text file in notepad

Windows seems to doing the translation inconsistently (I know
that comes as a shock...)

The command line processor parses the slash as a switch delimiter, but
the system call interface doesn't know about such refinements and treats
forward and backward slashes as filename component separators.

Just the same it's always cleanest to use os.path routines (or similar)
to analyze and construct filenames.

regards
Steve

 

[Dennis Lee Bieber]

C:\temp> REM try the same filename convention from dos prompt
C:\temp> type subdir/test.txt
The syntax of the command is incorrect.
C:\temp> REM try with quotes, just in case...
C:\temp> type "subdir/test.txt"
The syntax of the command is incorrect.
C:\temp> notepad subdir/test.txt
C:\temp> REM correctly opened the text file in notepad

Windows seems to doing the translation inconsistently (I know
that comes as a shock...)

"type" is a command shell built-in. "notepad" is a Windows
application. The command shell programs expect /xxx for command options.
I suspect Notepad doesn't have a command line option <G>, so just takes
the argument directly, and then uses it as is -- just as a Python open()
call can use it.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[jUrner]

C:\temp> REM try the same filename convention from dos prompt
C:\temp> type subdir/test.txt
The syntax of the command is incorrect.
C:\temp> REM try with quotes, just in case...
C:\temp> type "subdir/test.txt"
The syntax of the command is incorrect.
C:\temp> notepad subdir/test.txt
C:\temp> REM correctly opened the text file in notepad

Windows seems to doing the translation inconsistently (I know
that comes as a shock...)

Translation? win3.1 to win95 I guess.

 

[Tim Roberts]

Some experimentation shows that Python does seem to provide
*some* translation. Windows lets me use '/' as a path separator,
but not as the name of the root of a partition name. But perhaps
this a peculiarity of the commands themselves, and not of Windows
path names in particular.

C:\PYTHON24>CD /
The syntax of the command is incorrect.

C:\PYTHON24>CD \
C:\>EDIT /PYTHON24/README
The syntax of the command is incorrect.

The Windows APIs all accept either forward slashes or back, and have done
so clear back to Windows 3.0. However, the Windows command shells do not.
That's what you're seeing here.

 

[Neil Cerutti]

The Windows APIs all accept either forward slashes or back, and
have done so clear back to Windows 3.0. However, the Windows
command shells do not. That's what you're seeing here.

Well, kudos to Windows then for making Python look really smart
while making itself look like a dufus. ;-)

Seriously, experiments show the forward slash is OK as a
seperator, it just can't be root.

 

[Fredrik Lundh]

Seriously, experiments show the forward slash is OK as a
seperator, it just can't be root.

do you think you can figure out why, even without reading the various MSDN
pages you've been pointed to ?

</F>

 

[Neil Cerutti]

do you think you can figure out why, even without reading the
various MSDN pages you've been pointed to ?

Too late. Plus somebody else already pointed it out: command line
arguments.

 

[Tim Chase]

Some experimentation shows that Python does seem to provide

The Windows APIs all accept either forward slashes or back, and have done
so clear back to Windows 3.0. However, the Windows command shells do not.
That's what you're seeing here.

What one finds is that the command-shell is self-inconsistant:

C:\temp>md foo
C:\temp>md foo\bar
C:\temp>cd foo/bar
C:\temp\foo\bar>cd ..
C:\temp\foo>cd ..
C:\temp>cd /foo/bar
C:\temp\foo\bar>cd \temp
C:\temp>md foo/baz
The syntax of the command is incorrect
C:\temp>echo dir > foo/bar/pip
C:\temp>echo dir > /foo/bar/pip
The system cannot find the path specified.
C:\temp>dir foo/bar
Parameter format not correct - "bar".
C:\temp>dir /b foo\bar
pip
C:\temp>type foo/bar/pip
The syntax of the command is incorrect.
C:\temp>type foo\bar\pip
dir
C:\temp>cmd < foo/bar/pip
[directory listing within a subshell]
C:\temp>cmd < /foo/bar/pip
The system cannot find the path specified.


The CD, MD, TYPE, ECHO and redirection are all shell-builtins,
yet they seem to be conflictingly quasi-smart about forward slashes.

Sometimes leading slashes matter. Sometimes they don't.
Sometimes forward slashes are acceptable. Sometimes they aren't.
All within the shell's built-in mechanisms. Go figure.

-tkc

 

[Tim Chase]

This one does not work for me, but as long as the initial slash is back,
the rest can be foreward:

C:\tmp>cd /foo/bar
The system cannot find the path specified.
C:\tmp>cd \foo/bar
C:\foo\bar>

What OS are you running? Do you have the shell extensions enabled? The
latest cd does take a parameter (/d), so I wouldn't expect it to work.

This is cmd.exe on XP (SP2) with shell extensions enabled.

Note the subtle difference though...your "foo" is in the root
directory...mine is in the current directory. My result of

C:\temp>cd /foo/bar

is

C:\temp\foo\bar>

not

C:\foo\bar>

C:\temp>cmd < foo/bar/pip
[directory listing within a subshell]

I'm also surprised by this one. I'll file this away for my next NT
trivia contest...

You're a sick, sick fellow. I just stumbled across it while
trying various shot-in-the-dark permutations of command calls
with f-slashes and b-slashes in paths.

And strangely,

C:\temp>cmd < /temp/foo/bar/pip

fails as well. In more misadventures:

C:\temp>echo dir > zip
C:\temp>move zip foo/bar
C:\temp>dir /b foo\bar
pip
zip
C:\temp>move foo/bar/zip .
The system cannot find the path specified.

Okay...MOVE likes it as a destination, but not as a source.
Aaaggghh...If I had any hair, I'd be pulling it out. Move and
copy are similar options. Let's try copy:

C:\temp>move foo\bar\zip .
C:\temp>copy zip foo/bar
1 file(s) copied.
C:\temp>del zip
C:\temp>copy foo/bar/zip .
foo\zip
100% copied 1 file(s) copied.

<sarcasm>Of course! MOVE only accepts forward slashes in
destinations, not the source. But COPY accepts either.</sarcasm>
Maybe?

C:\temp>md foo\baz
C:\temp>dir /s/b
c:\temp\foo
c:\temp\zip
c:\temp\foo\bar
c:\temp\foo\baz
c:\temp\foo\zip
c:\temp\foo\bar\pip
c:\temp\foo\bar\zip

There's no "zip" in the "baz" directory, so let's copy it there:

C:\temp>copy foo/bar/zip foo/baz
foo\zip
Overwrite foo\zip? (Yes/No/All): y
The file cannot be copied onto itself.
0 file(s) copied.

What the [expletive]!? Well, there's a "zip" in our temp
directory, but no "pip". How about we try copying "pip" to the
"baz" directory instead while keeping the same syntax as above?

C:\temp>copy foo/bar/pip foo/baz
The syntax of the command is incorrect.

BLOODY MADNESS!

Some OS programmer doesn't seem to have graduated from their
CompSci program...

-tkc