[Pharo-project] Using Pharo from the command-line

Stuart Herring st-lists at stuartherring.com
Mon Sep 7 22:39:32 EDT 2009

On Tue, Sep 8, 2009 at 1:54 AM, Igor Stasenko<siguctua at 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
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)


More information about the Pharo-dev mailing list