Date: Mon, 28 Apr 1997 12:39:08 -0700 From: "Jin Guojun[ITG]" <jin@george.lbl.gov> To: gurney_j@resnet.uoregon.edu Cc: FreeBSD-gnats-submit@freebsd.org, bugs@freebsd.org Subject: Re: bin/3387: sh mis-interpret the file name / awk failure Message-ID: <199704281939.MAA21778@george.lbl.gov>
next in thread | raw e-mail | index | archive | help
} > >Description:
} >
} > In a script, if the variable for a file name had a white space at
} > the end, the sh will treat it differently when the file name variable
} > is used at redirected I/O, from used at fopen(). The white space is
} > interpreted as part of the file name when I/O redirections, such as,
} > '<', '<<', '>>', and '>' are used. This is a problem for using in
} > a script.
} > The FreeBSD awk generates such withe space:
} >
} > MyArch=`uname -v | awk -F/ '{printf $NF}`
} > echo "=$MyArch="
} > =GENERIC =
} >
} > I am not sure which one is the problem, maybe both.
}
} but of course... when you do the MyArch... it will store EXACTLY what awk
} outputed... and that is with a \n at the end... one simple fix is:
} MyArch=`uname -v | awk -F/ '{printf("%s", $NF)}'`
} MyArch=`echo $MyArch`
} echo "=$MyArch="
}
} the second setting of MyArch eliminates the \n at the end... I had a
} simlar problem with a script I was writing... it's just that borne shell
} does EXACTLY what you tell it... :)
It is not true. The awk for all other platforms does not output such \n.
May it is GNU awk's problem. At least, we need make things consistant around
the world. Why the tool with same name behaves differnetly cross platforms?
Also, I doubt GNU awk output \n. If you do this:
cat something > $MyArch
The file created will be "GENERIC " instead of "GENERIC\n".
} > >How-To-Repeat:
} >
} > For awk problem, see Description above.
} > Below is the sh issue:
} >
} > % more abc
} > file abc is a testing file
} >
} > % more test.script
} > FILE_NAME="abc "
} > more < $FILE_NAME
} > echo "=$FILE_NAME="
} > more $FILE_NAME
} >
} > % test.script
} > test.script: cannot open abc : no such file
} > =abc =
} > file abc is a testing file
}
} this is just as easy... basicly sh does the variable expansion.. then
} it does the "parsing" of the command line options... if you replaced
} the second more with:
} more "$FILE_NAME"
} you would have the same problem...
I do NOT understand what you mean --
replacing the second more with:
more "$FILE_NAME"
the second more is -- more "$FILE_NAME" -- if it is repleaced by itself,
what makes different? Also, the second more has no problem at all. Why first
one has?
} if you don't have any objections (as this is borne shell's expected
} behavior), I'll close this.. ttyl..
If you think that using standard I/O should be different from using fopen(),
then, you may close the case. The both problems just make whole world not
consistant.
Some original spec./stuff may have flaw. This does not mean defective is good.
That is why the new technology always replaces the old technology. Then, things
are moving forward. DOS expected behavior is like DOS, but why people try to
get rid of it? Intel 286 is expected to behave like 286, why Pentium? or
even Pentium-II? Why NOT Z80 or 8086?
If you think this is my objections, please take a consideration. Otherwise,
please ignore it.
Thanks,
-Jin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704281939.MAA21778>