On Fri, 5 Dec 2003, Malcolm J. Currie wrote:
> > As for Alan's comment concerning why the "+" is the obvious candidate.
> > This repeatedly failed for all the blazars I was reducing that had pluses
> > in but '-' was fine and all the other sources with underscores were okay.
>
> Also "+" is a metacharacter in grep and awk. "-" is too but only if it
> appears within brackets. Can the metacharacter be escaped?
If I put an \ in front of the plus sign things get worse:
!! Error reading file names from stream attached to shell process -
! Interrupted system call
!! No files found matching the file specification
!
'/export/data/timj/scuba/scd/blazars/x2107\+52/out/adam_4061/kappa_mon'.
!
!
!
!
!
!
!
and the ! lines go on forever. The command never returns!
>
> Just a quick thought on a different tack. Is it anything to do with
> "+<number>" being treated as a number rather than a string? Does
> inserting an "@" before the path help?
>
It does seem to be "+<number>" that causes the problem. Putting an @ in
front is the same as trying to escape the +.
Further investigations don't seem to help me. I know wihhc hds_open is
causing the problem:
hds_open($filename, 'READ', $ploc, $$status);
in NDF.pm (where I'm getting the parameter) but if I run that code outside
of the pipeline it works fine. Running hds_tune() prior to this call fixes
the problem in the pipeline. Does anyone know whether the ADAM system
configures something in HDS that triggers this filename expansion which
does not happen when I write a 5 line program that just opens the file?
Where do I find the code that does this (possibly to track down why the
error message is infinitely long). Expanding $HOME and ~ is one thing,
expanding +<number> is not so clear to me.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|