Double slashes cancel out in Iraf path
Nicola Caon wrote on Sep 26, 2008
Hi,
I've just noticed that when a string used as a path contains two adjacent slashes, they cancel out. The following example will make it clear:
More in general, it seems that this is true for an even number of repeated slashes, while an odd number will leave just one slash in the path. I checked this in v2.12.2a and v2.14 (Linux) and v2.14 MacIntel.
It's not that I define variables with extra slashes for fun; I was building a path string by appending to a Unix environment variable read using the envget command, something like:
with MYPATH already containing a trailing slash.
I'm not sure whether this is a feature of Iraf, and it's there for very good reasons, or is some sort of parser bug. As far as I know, in Linux/Unix extra slashes are silently ignored and thus completely harmless.
Thanks very much,
Nicola
I've just noticed that when a string used as a path contains two adjacent slashes, they cancel out. The following example will make it clear:
ecl> s1="/1/2/3/4/"
ecl> path(s1)
dhcp-dyn-55-44.a!/1/2/3/4/
ecl> s1="/1/2//3/4/"
ecl> path(s1)
dhcp-dyn-55-44.a!/1/23/4/
More in general, it seems that this is true for an even number of repeated slashes, while an odd number will leave just one slash in the path. I checked this in v2.12.2a and v2.14 (Linux) and v2.14 MacIntel.
It's not that I define variables with extra slashes for fun; I was building a path string by appending to a Unix environment variable read using the envget command, something like:
s1=envget("MYPATH")//"/some/subdirectory/"with MYPATH already containing a trailing slash.
I'm not sure whether this is a feature of Iraf, and it's there for very good reasons, or is some sort of parser bug. As far as I know, in Linux/Unix extra slashes are silently ignored and thus completely harmless.
Thanks very much,
Nicola
Mike Fitzpatrick wrote on Sep 26, 2008
Nicola,
It;s not a bug in the sense that the task is doing what it says it will, even if that's not what you expect 8-) Specifically, the argument to PATHNAMES is a template string in which you're allowed to use wildcards and other metacharacters to expand the template. In this case the '//' is being interpreted as the string-concatenation operator in the template.
One workaround for this in a script is to simply remove the duplicate, e.g.
If you know the envget returns a path with a trailing '/' you can also just leave it out of your string when you build the directory string.
Cheers,
-Mike
It;s not a bug in the sense that the task is doing what it says it will, even if that's not what you expect 8-) Specifically, the argument to PATHNAMES is a template string in which you're allowed to use wildcards and other metacharacters to expand the template. In this case the '//' is being interpreted as the string-concatenation operator in the template.
One workaround for this in a script is to simply remove the duplicate, e.g.
s1 = "/1/2//3/4/"
prinit (s1) | tr ("STDIN", "//", "/", collapse+)
If you know the envget returns a path with a trailing '/' you can also just leave it out of your string when you build the directory string.
Cheers,
-Mike
Nicola Caon wrote on Sep 26, 2008
Hi Mike,
thanks a lot for the very clear explanation. Of course the double slash is the concatenation operator, I wonder why I did not think of it myself.
It took me some head scratching though, before I realized that all those "no files found" where due to the double slash in the path string.
Cheers,
Nicola
thanks a lot for the very clear explanation. Of course the double slash is the concatenation operator, I wonder why I did not think of it myself.
It took me some head scratching though, before I realized that all those "no files found" where due to the double slash in the path string.
Cheers,
Nicola
Last post on Sep 26, 2008