My tcl-script can be called from anywhere. It uses a bunch of
auxiliary files, belonging to the same package as the script. They all
reside in either the same directory as the script, or in ../data,
where .. is 1 directory up from the location where the script is
stored.

--> How can I let my script find out where it resides in order to be
able to load its aux-files? Something like

set scriptdir [whereamI]

I don't like environment variables.

Thanks!


Arjan

On Dec 18, 5:25=A0pm, Arjan <arjan.van.d...@rivm.nl> wrote:
> My tcl-script can be called from anywhere. It uses a bunch of
> auxiliary files, belonging to the same package as the script. They all
> reside in either the same directory as the script, or in ../data,
> where .. is 1 directory up from the location where the script is
> stored.
>
> --> How can I let my script find out where it resides in order to be
> able to load its aux-files? Something like
>
> set scriptdir [whereamI]
>
> I don't like environment variables.
>
> Thanks!
>
> Arjan

source [file dirname [info script]]/otherfile.tcl

-Alex

On Dec 18, 8:38=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:
> On Dec 18, 5:25=A0pm, Arjan <arjan.van.d...@rivm.nl> wrote:
>
>
>
> > My tcl-script can be called from anywhere. It uses a bunch of
> > auxiliary files, belonging to the same package as the script. They all
> > reside in either the same directory as the script, or in ../data,
> > where .. is 1 directory up from the location where the script is
> > stored.
>
> > --> How can I let my script find out where it resides in order to be
> > able to load its aux-files? Something like
>
> > set scriptdir [whereamI]
>
> > I don't like environment variables.

> source [file dirname [info script]]/otherfile.tcl

Or a little more generally:

source [file join [file dirname [info script]] otherfile.tcl]

On Dec 18, 4:47=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> Or a little more generally:
>   source [file join [file dirname [info script]] otherfile.tcl]

With experience, you're best with this:
  source [file normalize [file join [pwd] [file dirname [info script]]
otherfile.tcl]]

Yes, that's long and rather tricky. However it's actually often better
to store the location of the script once and then reuse it where
appropriate. Like that, you can afterwards avoid using [pwd] which
means that any relative pathnames that the user supplies will continue
to have the same meaning as they expect. This improves the users'
perception of the app a lot.

On Dec 18, 4:58=A0pm, "Donal K. Fellows"
<donal.k.fell...@manchester.ac.uk> wrote:
> On Dec 18, 4:47=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
> > Or a little more generally:
> > =A0 source [file join [file dirname [info script]] otherfile.tcl]
>
> With experience, you're best with this:
> =A0 source [file normalize [file join [pwd] [file dirname [info script]]
> otherfile.tcl]]
>
> Yes, that's long and rather tricky. However it's actually often better
> to store the location of the script once and then reuse it where
> appropriate. Like that, you can afterwards avoid using [pwd] which
> means that any relative pathnames that the user supplies will continue
> to have the same meaning as they expect. This improves the users'
> perception of the app a lot.

Sounds good to me. I use a tiny framework, and the first order of
business is to establish an application root, which can be reused.
However, individual packages can still use my example to refer to
their own files. I actually never use [pwd] since I always know the
application root (the start file is always located at that point).

For instance, here is the beginning of my start file:

# Initialization file

namespace eval ::tnt {
    variable Initialized 0
    variable AOLserver 0
    variable rootDirectory
    variable packageRoot
    variable packages [list]
}

set ::tnt::rootDirectory [file dirname [info script]]
set ::tnt::packageRoot [file join $::tnt::rootDirectory packages]


Usually the [pwd] is somewhere above the location of this file, but
everything within this framework should stay within the application
root.

Since I have been burned by this before (you can't safely use [cd] in
a threaded application), I sometimes wonder if I shouldn't delete/
rename the [cd] command right before the above script runs. It is a
nice shell command, but doesn't make sense once an application is
running.

Besides [pwd] there is [file normalize]. I think the problem with my
setup above is in not using [file normalize].

On Dec 18, 6:15=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> On Dec 18, 4:58=A0pm, "Donal K. Fellows"
>
>
>
> <donal.k.fell...@manchester.ac.uk> wrote:
> > On Dec 18, 4:47=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
> > > Or a little more generally:
> > > =A0 source [file join [file dirname [info script]] otherfile.tcl]
>
> > With experience, you're best with this:
> > =A0 source [file normalize [file join [pwd] [file dirname [info script]=
]
> > otherfile.tcl]]
>
> > Yes, that's long and rather tricky. However it's actually often better
> > to store the location of the script once and then reuse it where
> > appropriate. Like that, you can afterwards avoid using [pwd] which
> > means that any relative pathnames that the user supplies will continue
> > to have the same meaning as they expect. This improves the users'
> > perception of the app a lot.
>
> Sounds good to me. I use a tiny framework, and the first order of
> business is to establish an application root, which can be reused.
> However, individual packages can still use my example to refer to
> their own files. I actually never use [pwd] since I always know the
> application root (the start file is always located at that point).
>
> For instance, here is the beginning of my start file:
>
> # Initialization file
>
> namespace eval ::tnt {
> =A0 =A0 variable Initialized 0
> =A0 =A0 variable AOLserver 0
> =A0 =A0 variable rootDirectory
> =A0 =A0 variable packageRoot
> =A0 =A0 variable packages [list]
>
> }
>
> set ::tnt::rootDirectory [file dirname [info script]]
> set ::tnt::packageRoot [file join $::tnt::rootDirectory packages]
>
> Usually the [pwd] is somewhere above the location of this file, but
> everything within this framework should stay within the application
> root.
>
> Since I have been burned by this before (you can't safely use [cd] in
> a threaded application), I sometimes wonder if I shouldn't delete/
> rename the [cd] command right before the above script runs. It is a
> nice shell command, but doesn't make sense once an application is
> running.
>
> Besides [pwd] there is [file normalize]. I think the problem with my
> setup above is in not using [file normalize].

Actually the following seems to work (at least on one platform) as I
was expecting:

set rootDirectory [file dirname [file normalize [info script]]]

I get the same results regardless of my pwd. Time to update my
script.

This doesn't remove the possibility that by mistake a [cd] could
change the pwd and break code which uses a raw relative path.

On Dec 18, 5:47=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> On Dec 18, 8:38=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> wrote:
>
>
>
>
>
> > On Dec 18, 5:25=A0pm, Arjan <arjan.van.d...@rivm.nl> wrote:
>
> > > My tcl-script can be called from anywhere. It uses a bunch of
> > > auxiliary files, belonging to the same package as the script. They al=
l
> > > reside in either the same directory as the script, or in ../data,
> > > where .. is 1 directory up from the location where the script is
> > > stored.
>
> > > --> How can I let my script find out where it resides in order to be
> > > able to load its aux-files? Something like
>
> > > set scriptdir [whereamI]
>
> > > I don't like environment variables.
> > source [file dirname [info script]]/otherfile.tcl
>
> Or a little more generally:
>
> source [file join [file dirname [info script]] otherfile.tcl]

Why more generally ? In what platform doesn't the / get mapped to the
appropriate separator ?

-Alex

On Dec 19, 9:17=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:
> On Dec 18, 5:47=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
>
>
> > On Dec 18, 8:38=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> > wrote:
>
> > > On Dec 18, 5:25=A0pm, Arjan <arjan.van.d...@rivm.nl> wrote:
>
> > > > My tcl-script can be called from anywhere. It uses a bunch of
> > > > auxiliary files, belonging to the same package as the script. They =
all
> > > > reside in either the same directory as the script, or in ../data,
> > > > where .. is 1 directory up from the location where the script is
> > > > stored.
>
> > > > --> How can I let my script find out where it resides in order to b=
e
> > > > able to load its aux-files? Something like
>
> > > > set scriptdir [whereamI]
>
> > > > I don't like environment variables.
> > > source [file dirname [info script]]/otherfile.tcl
>
> > Or a little more generally:
>
> > source [file join [file dirname [info script]] otherfile.tcl]
>
> Why more generally ? In what platform doesn't the / get mapped to the
> appropriate separator ?

So this is the hope and pray argument?

http://en.wikipedia.org/wiki/Path_(computing)

On Dec 19, 7:28=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> On Dec 19, 9:17=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> wrote:
>
>
>
>
>
> > On Dec 18, 5:47=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
> > > On Dec 18, 8:38=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.co=
m>
> > > wrote:
>
> > > > On Dec 18, 5:25=A0pm, Arjan <arjan.van.d...@rivm.nl> wrote:
>
> > > > > My tcl-script can be called from anywhere. It uses a bunch of
> > > > > auxiliary files, belonging to the same package as the script. The=
y all
> > > > > reside in either the same directory as the script, or in ../data,
> > > > > where .. is 1 directory up from the location where the script is
> > > > > stored.
>
> > > > > --> How can I let my script find out where it resides in order to=
 be
> > > > > able to load its aux-files? Something like
>
> > > > > set scriptdir [whereamI]
>
> > > > > I don't like environment variables.
> > > > source [file dirname [info script]]/otherfile.tcl
>
> > > Or a little more generally:
>
> > > source [file join [file dirname [info script]] otherfile.tcl]
>
> > Why more generally ? In what platform doesn't the / get mapped to the
> > appropriate separator ?
>
> So this is the hope and pray argument?
>
> http://en.wikipedia.org/wiki/Path_(computing)

Beg your pardon ?
Repeat, on what platform doesn't _Tcl_ map internal /-based paths to
native separators ?

-Alex

On Dec 19, 7:29=A0pm, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:
> Repeat, on what platform doesn't _Tcl_ map internal /-based paths to
> native separators ?

It didn't used to do so on Mac Classic. We don't support that platform
any more. This is because no developer of Tcl uses it (and Apple don't
support it either).

Donal.

On Dec 20, 1:46=A0am, "Donal K. Fellows"
<donal.k.fell...@manchester.ac.uk> wrote:
> On Dec 19, 7:29=A0pm, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> wrote:
>
> > Repeat, on what platform doesn't _Tcl_ map internal /-based paths to
> > native separators ?
>
> It didn't used to do so on Mac Classic. We don't support that platform
> any more. This is because no developer of Tcl uses it (and Apple don't
> support it either).

Ah, so it looks like the [source [file dirname [info script]]/
other.tcl] idiom now works across the board, doesn't it ?

-Alex

On Dec 20, 3:59=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:
> On Dec 20, 1:46=A0am, "Donal K. Fellows"
>
> <donal.k.fell...@manchester.ac.uk> wrote:
> > On Dec 19, 7:29=A0pm, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> > wrote:
>
> > > Repeat, on what platform doesn't _Tcl_ map internal /-based paths to
> > > native separators ?
>
> > It didn't used to do so on Mac Classic. We don't support that platform
> > any more. This is because no developer of Tcl uses it (and Apple don't
> > support it either).
>
> Ah, so it looks like the [source [file dirname [info script]]/
> other.tcl] idiom now works across the board, doesn't it ?

This doesn't work so well:

% set x /test.txt
/test.txt
% set y [file dirname $x]/c.mid
//c.mid

This does:

% set y [file join [file dirname $x] c.mid]
/c.mid

This does not work:
tom@boron:/$ cat /test.tcl
puts [file dirname [info script]]
puts [file dirname [info script]]/tmp.txt

tom@boron:/$ tclsh
% pwd
/
% source /test.tcl
/
//tmp.txt
% source test.tcl
..
../tmp.txt

On Dec 20, 3:59=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:
> On Dec 20, 1:46=A0am, "Donal K. Fellows"
>
> <donal.k.fell...@manchester.ac.uk> wrote:
> > On Dec 19, 7:29=A0pm, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> > wrote:
>
> > > Repeat, on what platform doesn't _Tcl_ map internal /-based paths to
> > > native separators ?
>
> > It didn't used to do so on Mac Classic. We don't support that platform
> > any more. This is because no developer of Tcl uses it (and Apple don't
> > support it either).
>
> Ah, so it looks like the [source [file dirname [info script]]/
> other.tcl] idiom now works across the board, doesn't it ?

Tcl's file commands are one of the reasons developers decide to use
tcl: they provide portability and _safety_. There is nothing
interesting about the special case solution shown here. Even my
original solution had problems, corrected by Donal. Why not promote
good practices instead of hacks?

The problem with the special case hack is that there is no way to
analyze the safety and generality of the code. Under what conditions
will it work? When can it be used? General solutions to common
problems are "reusable". And once they are understood, they take much
less mental energy to use and maintain. The special case hack is just
a bug which works most of the time...just like buffer overflows and
unsanitized user data.

Interestingly it looks like the tools to work with the HFS virtual
filesystem (which uses : as sep) are partly written in Tcl. Since
promotion of virtual filesystems seems to be a goal of the Tcl
community, why not maintain some level of support, maybe even a little
pride in the ability to write portable code?

On Dec 20, 8:33=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> On Dec 20, 3:59=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> wrote:
>
> > On Dec 20, 1:46=A0am, "Donal K. Fellows"
>
> > <donal.k.fell...@manchester.ac.uk> wrote:
> > > On Dec 19, 7:29=A0pm, Alexandre Ferrieux <alexandre.ferri...@gmail.co=
m>
> > > wrote:
>
> > > > Repeat, on what platform doesn't _Tcl_ map internal /-based paths t=
o
> > > > native separators ?
>
> > > It didn't used to do so on Mac Classic. We don't support that platfor=
m
> > > any more. This is because no developer of Tcl uses it (and Apple don'=
t
> > > support it either).
>
> > Ah, so it looks like the [source [file dirname [info script]]/
> > other.tcl] idiom now works across the board, doesn't it ?
>
> Tcl's file commands are one of the reasons developers decide to use
> tcl: they provide portability and _safety_. There is nothing
> interesting about the special case solution shown here. Even my
> original solution had problems, corrected by Donal. Why not promote
> good practices instead of hacks?
>
> The problem with the special case hack is that there is no way to
> analyze the safety and generality of the code. Under what conditions
> will it work? When can it be used? General solutions to common
> problems are "reusable". And once they are understood, they take much
> less mental energy to use and maintain. The special case hack is just
> a bug which works most of the time...just like buffer overflows and
> unsanitized user data.
>
> Interestingly it looks like the tools to work with the HFS virtual
> filesystem (which uses : as sep) are partly written in Tcl. Since
> promotion of virtual filesystems seems to be a goal of the Tcl
> community, why not maintain some level of support, maybe even a little
> pride in the ability to write portable code?

Hey Tom, you're back to lecturing mode. Remember how verbosely you
explained how buffered I/O couldn't possibly be fixed ? See a
pattern ?

-Alex

On Dec 19, 1:58=A0am, "Donal K. Fellows"
<donal.k.fell...@manchester.ac.uk> wrote:
> On Dec 18, 4:47=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
> > Or a little more generally:
> > =A0 source [file join [file dirname [info script]] otherfile.tcl]
>
> With experience, you're best with this:
> =A0 source [file normalize [file join [pwd] [file dirname [info script]]
> otherfile.tcl]]
>
> Yes, that's long and rather tricky. However it's actually often better
> to store the location of the script once and then reuse it where
> appropriate. Like that, you can afterwards avoid using [pwd] which
> means that any relative pathnames that the user supplies will continue
> to have the same meaning as they expect. This improves the users'
> perception of the app a lot.

Hello Donal

Could you please give me a situation where pwd is required ? I can't
figure it out.
Thanks !

On Dec 20, 2:14=A0pm, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:
> On Dec 20, 8:33=A0pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
>
>
> > On Dec 20, 3:59=A0am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> > wrote:
>
> > > On Dec 20, 1:46=A0am, "Donal K. Fellows"
>
> > > <donal.k.fell...@manchester.ac.uk> wrote:
> > > > On Dec 19, 7:29=A0pm, Alexandre Ferrieux <alexandre.ferri...@gmail.=
com>
> > > > wrote:
>
> > > > > Repeat, on what platform doesn't _Tcl_ map internal /-based paths=
 to
> > > > > native separators ?
>
> > > > It didn't used to do so on Mac Classic. We don't support that platf=
orm
> > > > any more. This is because no developer of Tcl uses it (and Apple do=
n't
> > > > support it either).
>
> > > Ah, so it looks like the [source [file dirname [info script]]/
> > > other.tcl] idiom now works across the board, doesn't it ?
>
> > Tcl's file commands are one of the reasons developers decide to use
> > tcl: they provide portability and _safety_. There is nothing
> > interesting about the special case solution shown here. Even my
> > original solution had problems, corrected by Donal. Why not promote
> > good practices instead of hacks?
>
> > The problem with the special case hack is that there is no way to
> > analyze the safety and generality of the code. Under what conditions
> > will it work? When can it be used? General solutions to common
> > problems are "reusable". And once they are understood, they take much
> > less mental energy to use and maintain. The special case hack is just
> > a bug which works most of the time...just like buffer overflows and
> > unsanitized user data.
>
> > Interestingly it looks like the tools to work with the HFS virtual
> > filesystem (which uses : as sep) are partly written in Tcl. Since
> > promotion of virtual filesystems seems to be a goal of the Tcl
> > community, why not maintain some level of support, maybe even a little
> > pride in the ability to write portable code?
>
> Hey Tom, you're back to lecturing mode. Remember how verbosely you
> explained how buffered I/O couldn't possibly be fixed ? See a
> pattern ?

Only pattern is your inability to understand what I'm saying (Get in
line.) I never said impossible, I said if it is a bug, it is more
complicated than demonstrated in your bug report. But if I remember
correctly, your first patch ignored my advice and followed those who
agreed with you. The second patch, which actually worked...perfectly,
followed my analysis of the situation. Somewhere in the middle there
was crazy talk about readjusting the buffer boundaries. My main points
were that the patch needed to be high level, possibly using helper
functions, and not increase the number of flush/seek calls under the
covers...for any code.

I also identified an interaction when using buffering and the buffer
size. This was the most easily demonstrated bug, if it had been
noticed. This fell into your original description of the bug: changing
channel options leads to different results on alternating input/
output.

So overall, I would say the pattern is that you rely on a much smaller
data set when making decisions, and tend to be more dogmatic, in the
long run, than I am.

What I don't really understand is your hostility. In your i/o bug fix,
I created 144 different i/o test configurations. I actually spent
considerable time developing a test program. Did I do this for your
benefit, for mine, or as a reasonable check on fact-free commentary?
My little test program proved that with your patch no existing (bug
free) code would work differently in any way (some buggy code might
start working correctly). Future code could take advantage of your
patch. And maybe even more importantly, small changes to existing code
will not introduce new bugs...the original motivation for the bug
report.

My personal opinion on this patch: please write this up and maybe give
a lecture. This solution is by far the new standard for buffered i/o.
It isn't even close. This isn't small stuff. Of course you have to
realize that the solution was possible because of the high quality of
the Tcl channel code.

On Dec 21, 3:23=A0am, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
> Only pattern is your inability to understand what I'm saying (Get in
> line.)

Yes. Specifically, the following superset of your prose drives me
crazy:

    (blah){100,1000}(valuable insight)?(blah){100,1000}

-Alex

tom.rmadilo wrote:
> On Dec 20, 3:59 am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> wrote:
>> On Dec 20, 1:46 am, "Donal K. Fellows"
>>
>> <donal.k.fell...@manchester.ac.uk> wrote:
>>> On Dec 19, 7:29 pm, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
>>> wrote:
>>>> Repeat, on what platform doesn't _Tcl_ map internal /-based paths to
>>>> native separators ?
>>> It didn't used to do so on Mac Classic. We don't support that platform
>>> any more. This is because no developer of Tcl uses it (and Apple don't
>>> support it either).
>> Ah, so it looks like the [source [file dirname [info script]]/
>> other.tcl] idiom now works across the board, doesn't it ?
> 
> This doesn't work so well:
> 
> % set x /test.txt
> /test.txt
> % set y [file dirname $x]/c.mid
> //c.mid
> 

what isn't "working" here?

> This does:
> 
> % set y [file join [file dirname $x] c.mid]
> /c.mid
> 
> This does not work:
> tom@boron:/$ cat /test.tcl
> puts [file dirname [info script]]
> puts [file dirname [info script]]/tmp.txt
> 
> tom@boron:/$ tclsh
> % pwd
> /
> % source /test.tcl
> /
> //tmp.txt
> % source test.tcl
> .
> ./tmp.txt
> 

again what is "not" working.

in each of your cases if you do

set fd [open $myComputedName]
set str [read $fd]
close $fd
puts "Contents are: $str"

tell me the differences of the ones that "work"
and the ones the "don't work"

Bruce

On Dec 21, 8:33=A0am, Bruce Hartweg <doNOTmai...@example.com> wrote:
> tom.rmadilo wrote:
> > On Dec 20, 3:59 am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> > wrote:
> >> On Dec 20, 1:46 am, "Donal K. Fellows"
>
> >> <donal.k.fell...@manchester.ac.uk> wrote:
> >>> On Dec 19, 7:29 pm, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
> >>> wrote:
> >>>> Repeat, on what platform doesn't _Tcl_ map internal /-based paths to
> >>>> native separators ?
> >>> It didn't used to do so on Mac Classic. We don't support that platfor=
m
> >>> any more. This is because no developer of Tcl uses it (and Apple don'=
t
> >>> support it either).
> >> Ah, so it looks like the [source [file dirname [info script]]/
> >> other.tcl] idiom now works across the board, doesn't it ?
>
> > This doesn't work so well:
>
> > % set x /test.txt
> > /test.txt
> > % set y [file dirname $x]/c.mid
> > //c.mid
>
> what isn't "working" here?
>
>
>
> > This does:
>
> > % set y [file join [file dirname $x] c.mid]
> > /c.mid
>
> > This does not work:
> > tom@boron:/$ cat /test.tcl
> > puts [file dirname [info script]]
> > puts [file dirname [info script]]/tmp.txt
>
> > tom@boron:/$ tclsh
> > % pwd
> > /
> > % source /test.tcl
> > /
> > //tmp.txt
> > % source test.tcl
> > .
> > ./tmp.txt
>
> again what is "not" working.
>
> in each of your cases if you do
>
> set fd [open $myComputedName]
> set str [read $fd]
> close $fd
> puts "Contents are: $str"
>
> tell me the differences of the ones that "work"
> and the ones the "don't work"

Maybe the concept of general as opposed to "special case" isn't
clear?

Imagine that you compute the path as //tmp.txt.

The next step is to divide the path into components: [split //
tmp.txt /]

Oops! No longer works. Using [file join] is also more general because
it understands that each component is a path fragment. [file dirname
[info script]] is one way to generate a path fragment, it usually
returns a string which does not end in /. But any directory path can
be represented with or without a trailing /. Of course [file split]
takes care of these problems.