The unusual/strange behaviors - Super Thread.

Hi Friends,

Recently I came upon a new discovery in bash shell that commands which expect input <paths> as parameters like ls, rm works even if you type multiple front slashes

for eg.
rm /foo/bar/file.txt
works even if we type it as
rm /foo//bar/file.txt

or even
ls /foo/////bar///file or to my surprise
even ///foo/bar/file.txt works.
I'm using RHEL 5.
Its a strange behaviour to me as I wonder why it happened. Could anyone explain it more deeply??...

Or if you too come across some strange things then do share it here as everyone would love to know such things ...

It was UNIX behaviour, too, presumably because there is no ambiguity so there's no benefit (except pedantry) in rejecting paths with multiple consecutive "/" characters.

Here's a strange thing -- looking through zero reply threads and finding something labeled "Super Thread". A bit presumptuous, don't you think?

I tried your oddity in ksh on Solaris, and it works the same way.

I might have expected a syntax error, but, on the other hand, there's really no other interpretation. The extra / is either nothing or a syntax error.

This behaviour is also defined by the POSIX standard, i.e. quoting the definition of PATHNAME from IEEE Std 1003.1-2001:

A character string that is used to identify a file. In the context of IEEE Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes, including the terminating null byte. It has an optional beginning slash, followed by zero or more filenames separated by slashes. A pathname may optionally contain one or more trailing slashes. Multiple successive slashes are considered to be the same as one slash.

Thanks colucix

Actually I came across this as I found that one of my scripts was not working properly; some of the lines are...

basepath=/backup/rman/
rm $basepath/arc*

While debugging I found that it actually expands to
rm /backup/rman//arc*
And I thought that I found the bug.

Then I executed rm /backup/rman//arc* from command prompt and it worked well (to my surprise).
BUT it was not working from inside the script which was scheduled by cron. This irritated me the most as the same command executes from the command line but not from within the script. This again is unusual...