Mailing List Archive

On Wed, 13 Sep 1995, Tim Bunce wrote:

> In article <YHLUCHAN.95Sep12131807@cherokee>, <yhluchan@ops.raynet.com> wrote:
> > Hi, just a feature request creeping up! It'll make writing portable
> > scripts easier. I'd like a regexp syntax for file boundries- something
> > that will match the directory seperator for the platform perl is
> > running on, or beginning/end of line. If it were called '\f' then
> >
> > ($head, $end) = /(.*?\f)(.+)$/
> >
> > would break '../foo' into '../', 'foo' on a unix system
> > '..\foo.dat' into '..\', 'foo.dat' on a dossish box
> > ':Foo example' into ':' , 'Foo example' on a Macintosh
> > 'foo' into '' , 'foo' on any system
> >
> > Don't know what the dirsep is on VMS, but you get the idea.
> >
> > I know I can write a sub to set some variable that I can use in place
> > of this, or use Basename for 95% of what this would be used for-
> > just an idea.
> >
> Interesting. Just getting Configure to record what the file separator
> is would suffice. Then you could say things like:
>
> $fs = $Config{'filesep'};
>
> @parts = split(/\Q$fs\E/, $_);

It looks like we need two different items: the path separator, and the
PATH separator. For DOS, that's '\' and ';'. For Unix, it's '/' and ':'.
Of course, actually that isn't true about DOS. It's a little known fact,
but the directory separator for DOS is really [\\/], i.e., forward slashes
work just fine in the internals of DOS, and in an open() call, it's only
programs that try and parse switches on their command lines that chew
these files up.

So should $Config{'filesep'} be '[\\/]' or '\\' under DOS? And is there
anything else other then filesep and pathsep that can be expressed simply.
(I don't think DOS drive letters can.)

> > -yary
> Tim.

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

Kenneth Albanowski writes:
> It looks like we need two different items: the path separator, and the
> PATH separator. For DOS, that's '\' and ';'. For Unix, it's '/' and ':'.
> Of course, actually that isn't true about DOS. It's a little known fact,
> but the directory separator for DOS is really [\\/], i.e., forward slashes
> work just fine in the internals of DOS, and in an open() call, it's only
> programs that try and parse switches on their command lines that chew
> these files up.
>
> So should $Config{'filesep'} be '[\\/]' or '\\' under DOS? And is there
> anything else other then filesep and pathsep that can be expressed simply.
> (I don't think DOS drive letters can.)
>

I will add path_sep (':' on *nix) to the Configure patch I'm doing
soon. However, the above distinction between dir_sep_read (=[\\/] on
DOS) and dir_sep_write (that for COMMAND.COM shell should be '\\', for
ksh may be '/' is better, I do not know) should be discussed more
here.

Note that in my OS/2 patch I use only '/'. There are 2 or 3 cases
where I needed to convert from \\ to /, like when splitting the
PATH. However, I used ksh as shell in the cases I considered.

On the other hand, there is EMACS interface to paths, that we may just
blindly copy here. It contains functions like file-name-anchored,
file-name-rooted and so on (there are ways to anchor file name to
other places that root under DOS).

Ilya

On Wed, 13 Sep 1995, Ilya Zakharevich wrote:

> I will add path_sep (':' on *nix) to the Configure patch I'm doing
> soon. However, the above distinction between dir_sep_read (=[\\/] on
> DOS) and dir_sep_write (that for COMMAND.COM shell should be '\\', for
> ksh may be '/' is better, I do not know) should be discussed more
> here.

Ah, I see what you mean. \ or / may be incoming, but only \ should go out in
DOS. Except when somebody has written something that says it shouldn't... We
may be able to plug some decent defaults into Configure, but it's there is no
way that they will be useful in all possible circumstances.

> Note that in my OS/2 patch I use only '/'. There are 2 or 3 cases
> where I needed to convert from \\ to /, like when splitting the
> PATH. However, I used ksh as shell in the cases I considered.

But and perl program running under OS/2 is as likely to see paths on the
command line using \ as /, and that's the key.

Having a path_sep variable (containing ';' for OS/2) definitely seems to be a
good idea.

> On the other hand, there is EMACS interface to paths, that we may just
> blindly copy here. It contains functions like file-name-anchored,
> file-name-rooted and so on (there are ways to anchor file name to
> other places that root under DOS).

Sigh. One more think to take a look at.

> Ilya

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

> From: Kenneth Albanowski <kjahds@kjahds.com>
>
> On Wed, 13 Sep 1995, Ilya Zakharevich wrote:
>
> > I will add path_sep (':' on *nix) to the Configure patch I'm doing
> > soon. However, the above distinction between dir_sep_read (=[\\/] on
> > DOS) and dir_sep_write (that for COMMAND.COM shell should be '\\', for
> > ksh may be '/' is better, I do not know) should be discussed more
> > here.
>
> Ah, I see what you mean. \ or / may be incoming, but only \ should go out in
> DOS. Except when somebody has written something that says it shouldn't... We
> may be able to plug some decent defaults into Configure, but it's there is no
> way that they will be useful in all possible circumstances.
>
> > Note that in my OS/2 patch I use only '/'. There are 2 or 3 cases
> > where I needed to convert from \\ to /, like when splitting the
> > PATH. However, I used ksh as shell in the cases I considered.
>
> But and perl program running under OS/2 is as likely to see paths on the
> command line using \ as /, and that's the key.
>
> Having a path_sep variable (containing ';' for OS/2) definitely seems to be a
> good idea.
>
> > On the other hand, there is EMACS interface to paths, that we may just
> > blindly copy here. It contains functions like file-name-anchored,
> > file-name-rooted and so on (there are ways to anchor file name to
> > other places that root under DOS).
>
> Sigh. One more think to take a look at.
>
Having brought this issue to perl5-porters I've now changed my mind.

I don't believe it's practical to express file path syntax for all perl
ports with just a couple of variables (consider VMS as a worst case :-).

I'd rather see File::Basename (which should have been renamed File::Path)
extended and optimised.

Tim.