file function and directory separator troubles...

As I'm currently porting many scripts from unix to windows and writing
new ones for both platforms I've found some troubles using the file
split/join function.
The reason is, that [file join] always uses the forward slash as
directory separator. So you always have to distinguish if the resulting
path name is used within tcl (which makes no troubles) or if the results
are used by the "system" windows.

I found at least 3 situations where the file function cannot be used
to manage file paths unreflectingly:
1. when creating files which will be executed by the system. An
example is writing a batch file using path names in commands, eg.:
% puts $batchfile "@echo off\n[file join $basedir $module startup.exe]"
2. when using file join with environment variables for path names, eg.:
% if {$env(EXE_NAME) eq [file join $basedir $module startup.exe]} ...
3. when using joined path names in exec (or pipes). E.g. the command
% exec acrobat [file join $docdir $module help.pdf]
fails with acrobat reader 8.
I've found that the last problem is in general a acrobat reader
behaviour, but if the [file join] would use "native" directory
separators, the problem would not occur.

All these cases require a special handling on the generated path names,
which makes the platform independency of these functions inoperatively.

Some questions:
1. Does anyone have a solution for this (except doing regsub -all ...
on each path name)?
2. Should this behaviour become changed in general. IMHO I do not see
any reason to keep this behaviour for "compatibility" reasons?
3. Would that be worth to write a TIP to add an option to the
file subcommands to use the "native" separators.
I'm afraid it would be too late for 8.5?

--
Gerhard Reithofer
Tech-EDV Support Forum - http://support.tech-edv.co.at
.

Relevant Pages

  • Re: file function and directory separator troubles...
    ... writing new ones for both platforms I've found some troubles using ... the file split/join function. ...
    (comp.lang.tcl)
  • Re: Web Application Testers.
    ... > automatically alerts you to the latest security vulnerabilities please see: ... Platforms: ... A Windows/MS-DOS CGI scanner which scans for 65 remote ... Windows 2000 and Windows NT ...
    (Vuln-Dev)
  • Re: Web Application Testers.
    ... > automatically alerts you to the latest security vulnerabilities please see: ... Platforms: ... A Windows/MS-DOS CGI scanner which scans for 65 remote ... Windows 2000 and Windows NT ...
    (Pen-Test)
  • Re: truncating text fields
    ... I'll take a look at the font issue again, but as I said before, I don't have any problems rendering 6 pt Times New Roman in other software, so I don't think it is a system configuration or font problem. ... Though I think to a large extent the reason why Java has failed as a UI vehicle is because users of different platforms are not as concerned with seeing the exact pixel-for-pixel representation of the same UI on different platforms, as they are with having the UI work as expected on their chosen platform. ... That being said, if it comes between having a less than optimal FM on Windows vs. no version at all, I would obviously take the former. ... I can understand why a hard-core developer might feel a little constrained by FileMaker Pro. ...
    (comp.databases.filemaker)
  • Re: Socket.Disconnect Method
    ... method that only worked on platforms prior to Windows ... method is supported on Windows 2000 and Windows 98, ... An error occurred when attempting to access the socket. ... It looks to me like the underlying error code could have been: ...
    (microsoft.public.vsnet.general)