On Tue, Sep 8, 2009 at 1:54 AM, Igor Stasenko<siguctua@gmail.com> wrote:
The problem with command-line arguments as a file names, like:
cat myfile.foo
is that the location of myfile.foo is determined by using a search path , usually provided in environment PATH var of a shell.
That's not actually true - the location is always relative to the current working directory. PATH is only used to locate _executables_ to be run, and is not used for finding command line options.
I worked in a different unix shells, and some of them, do not adding/using the ./ into the search path by default, which means that cat myfile.foo will end up with 'file not found' message, while cat ./myfile.foo will work fine. On which shells do you see this behaviour? I think you may be confusing it with the fact that:
myscript.sh myfile.foo won't work, but ./myscript.sh myfile.foo will - which is indeed because '.' is never in PATH. However, it won't make any difference to the ability of the program to locate "myfile.foo". The shell actually plays no part in locating a file specified as an argument on the command line, it's entirely up to the program using that command line how it will handle it. But on all Unix like platforms I've seen, if you pass simply "myfile.foo" to fopen(), it will look for the file in and only in the current working directory of the process. What can confuse the situation is if something changes the current working directory between the user passing in the argument, and the fopen() call being made. This might happen if for example, the command the user executed was actually a wrapper script that cd'd to another directory before running the actual command. (Though such a wrapper script, particularly for a program that did in fact expect files to be passed in on the command line, is arguably broken) Regards, Stuart