Command Line Arguments & Environmental Variables 
Author Message
 Command Line Arguments & Environmental Variables



Quote:

>Subject:Re: Command Line Arguments & Environment Variables Proposal
>Date: 15 Jan 1997 15:44:59 -0800

>As Craig surely knows (but many posters apparently do not), this
>"feature" (it's really more than one ;>) has been proposed to J3 and
>WG5 *many* times before, and rejected (as it was, by evidence of the
>committee vote) a POSIX/OS issue and not a language issue.

    As Keith surely knows (but many posters apparently do not), X3J3 had a
series of straw votes on this and many other proposed features for fortran
2000 at the last meeting (Nov. 11-15).  Here is the result of the straw vote
on Command Line Arguments and Environmental Variables:
        7 Yes
        7 No
While this is hardly a ringing endor{*filter*}t, by no means is it strong
rejection, either.

    In contrast, a complete Fortran 90 binding to POSIX got the following
votes:
         2 Yes
        11 No
One of the "Yes" votes was mine.

Quote:
>It is arguably unhelpful in the extreme to consume scarce committee

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quote:
>time to revisit issues settled (repeatedly, and not all that long ago

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Quote:
>for the last repeat bout). At least one would hope that a committee
>member who brings the issue back would pretend to have "new
>information" which would provide a logical basis for reversing the
>previous decision (if there was any in Craig's latest edition of the
>proposal it escaped me).

>I, of course, am speaking neither for neither Sun, ISO nor ANSI.

>--


> 2550 Garcia UMPK16-304   415 786-9296   | (415 7869296) fax
>Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1997

    Why should one need to have "new information" in order to bring an issue
back?  I believe that all that is needed is:

        *** SIGNIFICANT INTEREST from the Fortran user community ***

That one requirement is, in and of itself, sufficient.  No other
qualification is necessary.

    Unfortunately, the attitude that once an idea is rejected, it should
never be considered again, is quite prevalent among the membership of X3J3.  
This is based on my personal observation.  I really do not know why.

    I am troubled by the attitude that once rejected, a feature should never
be revisited.  If this is the norm for decision making, how could we ever
make any progress?  Most ideas are turned down several times before they are
accepted.

    Hmmm . . . let's apply Keith's reasoning to several (14) events from
world history.  I will leave it to readers to draw their own conclusions as
to whether we are better off because certain individuals did not give up
after repeated rejection and failure.

    1.  If Moses had given up after his first meeting with Pharoah, the
Israelites would still be slaves in Egypt today.  According to my count,
Moses had to make 13 attempts before he and the Israelites left Pharoah and
his army behind.

    2.  In 722 BC, the Assyrians deported the 10 northern tribes of Israel
into what is now northeastern Syria and assimilated them into the
surrounding population.  In 586 BC, Nebuchadnezzar conquered Judah, burned
the Temple to the ground, and deported the population to Babylonia.  Yet,
Ezekiel and his friends put together the Torah for the benefit of future
generations.

    3.  Confucius talked to whoever he could about his philosophy all of his
{*filter*} life, even though few would listen.  Today, 2500 years later, his
philosophy is the foundation of almost all of the societies of the Far East.  
Singapore's tough on crime attitude is solidly founded in Confucian
philosophy.

    4.  Buddha travelled all over India for 60+ years and talked to whoever
would listen about the value he placed on spiritual enlightenment.

    5.  Jesus of Nazareth was rejected by the chief priests, scribes, and
religious leaders of his day, as well as by their Roman overlords,
eventually dying on a Roman cross.  Yet his disciples carried on, in spite
of hardship, persecution, and terror.  As a result, over 1 billion people
today are Christians, instead of pagans.

    6.  Martin Luther carried on his efforts to reform the Church, even
though the Emperor Charles V and the Pope were not interested in the ideas
which he wrote in his 95 Theses.

    7.  The idea of human liberty fell to tyrants in ancient Greece and
Rome.  Yet in 1776, Thomas Jefferson and his friends still decided to write
"We hold these truths to be self-evident, that all men are created equal,
that they are endowed by their Creator with certain inalienable rights, that
among these rights are life, liberty and the pursuit of happiness..." and
produced the Declaration of Independence.

    8.  12 years later, in spite of previous conferences which failed,
James Madison, George Washington, and the rest of the Founders decided to
meet in Phildelphia in 1787 in order to improve the Articles of
Confederation.  While they met they produced the Constitution of the United
States of America.

    9.  Austria, Czechoslovakia, Poland, Denmark, Norway, Netherlands,
Belgium, France.  By June 1940, all of these nations fell to the Nazi
onslaught.  Yet, in spite of 8 years in the political wilderness, during
which time few people listened, Winston Churchill rallied the British people
to defend the free world against the tyranny of Adolf Hitler.

    10.  Estonia, Latvia, Lithuania, Poland, Czechoslovakia, Hungary,
Yugoslavia, Albania, Romania, Bulgaria, and the eastern half of Germany.  By
May 1945, Joe Stalin had conquered all of these and had intentions of
conquering Turkey, Greece, and Western Europe.  Yet Harry Truman sponsored
the Marshall Plan, spent millions of American tax dollars, and decided not
cede the rest of Europe to the aggression of one of the biggest butchers of
the 20th century.

    11.  For centuries it had been ruled by autocratic Prussian kings.  The
Weimar Republic fell to Adolf Hitler.  Yet in 1949, Germans tried once again
to create a stable democracy and a genuinely free society.

    12.  The president who sponsored the program was assassinated and
several direct participants died in the effort.  Yet, America still stayed
the course and in July 1969 landed a man on the moon.

    13.  In spite of over 60 years of steady losses and strong criticism at
home, in the 1980s Ronald Reagan decided to try one more time to bring down
the Soviet Union's Evil Empire.  It fell in December 1991.

    14.  In spite of 45 years of "Nyet" from the Russians, in 1989 German
Chancellor Helmut Kohl tried once again to reunify Germany.  He accomplished
that by December 1990.

----------
Sincerely,

Elmbrook Computer Services      Voice Phone: (414) 783-5869
17130 W. Burleigh Place        
Brookfield, WI   53005          Disclaimer:  These opinions are mine alone.
USA                             They do NOT represent any organization.

"They that can give up essential liberty to obtain a little temporary
    safety deserve neither liberty nor safety."  -- Benjamin Franklin (1759)



Wed, 07 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables



[snip]

Quote:
>2000 at the last meeting (Nov. 11-15).  Here is the result of the straw vote
>on Command Line Arguments and Environmental Variables:
>    7 Yes
>    7 No
>While this is hardly a ringing endor{*filter*}t, by no means is it strong
>rejection, either.

[snip]

Getting command line arguments is a feature that is available in so many
Fortrans.  So many people ask about it that it has its own FAQ.  Why is
the "standards" committee so neutral about whether it should be officially
included?

[snip]

Quote:
>to defend the free world against the tyranny of Adolf Hitler.

[snip]

Gee - and I thought I was harsh in my comments about the committee. :-)

Ken Plotkin



Thu, 08 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables


[snip]

Quote:
>The problem is that what most Fortran users want from the feature is not
>possible under UNIX operating systems: to get the whole, unparsed
>command line.  This convinces others on the committee that the feature

[snip]

Why do people want the whole, unparsed line?  Speaking for myself, I
always want to get the arguments.  The times where I did get the whole
line (GWBASIC and Lahey Fortran, on a PC) I thought it was a nuisance to
have to parse it down to the arguments myself.

It seems a little out of touch to avoid standardizing a common extension
because some systems are capable of fancier versions.  Standardization
does involve some least-common-denominator compromises.

Ken Plotkin



Thu, 08 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables

Quote:


> [snip]
> >The problem is that what most Fortran users want from the feature is not
> >possible under UNIX operating systems: to get the whole, unparsed
> >command line.  This convinces others on the committee that the feature
> [snip]

> Why do people want the whole, unparsed line?  Speaking for myself, I
> always want to get the arguments.  The times where I did get the whole
> line (GWBASIC and Lahey Fortran, on a PC) I thought it was a nuisance to
> have to parse it down to the arguments myself.

I want to get the arguments too.  So that if I have a calculator
program, the command line:

   calc pi*x/180

should not return an incorrect list of files "globbed" from the local
file list, but the result of the expression.  The assumption you are
making is that what constitutes "the arguments" is defined the same for
all processes.  That is simply not the case.  It is no trouble at all to
have a standardized parsing tool which you can pass the whole command
line into - and which you can independently configure for different
syntax requirements for different programs.  If you are completely
satisfied with just one such configuration you can simply include the
same code into every program and not worry about it - just like you do
in UNIX now (it will just be different code - not harder).  But it will
give the rest of us the flexibility we want.

Not only are the parsing rules sometimes different from one program to
another, but so are the interpretations of the token even when the same
parse is used.

   ls aa*

This should list the local files whose names begin with 'aa'.

   rls machine-name aa*

This should be able to list the files beginning with 'aa' on the named
remote machine.

   phone aa*

This should be able to list the online phonebook listings for names
beginning with 'aa'.

Etc....

In other words, I not only want to be inconsistent about the way command
lines are interpreted when it's appropriate to be so, I sometimes want
to be *consistent* about the way command lines are interpreted in ways
the UNIX protocol does not permit.

[...]

Quote:
> It seems a little out of touch to avoid standardizing a common extension
> because some systems are capable of fancier versions.  [...

So, write a supplimentary standard.  There are lots of things which the
committee correctly regards as beyond the scope of the language standard
(like the collating sequence of the character set, or the size and
representation of floating-point numbers).  Many of these (including the
two I mention) are described in other standards.  This is done with the
understanding on the part of everyone involved that a Fortran
implementation is not *required* to adopt any particular external
standard, not is any external standard restricted to apply only to
Fortran.

Quote:
> ...]                                             Standardization
> does involve some least-common-denominator compromises.

Yes, but usually with respect to things that are beyond the scope of the
language itself, these compromises are implicit.  As long as the
standard doesn't include requirements which *prohibit* a given
mechanism, you could have implementations which can choose that
mechanism.  Fortran doesn't prohibit call by value/result
(copy-in/copy-out semantics), so an implementation is free to choose
that for remote procedure calls (where this is the most efficient
mechanism).  Fortran doesn't make to many assumptions about the
character set or the floating-point implementation, so it can be used in
several different systems, several different countries, and with several
different kinds of hardware.  I certainly would not want the standard to
*define* command line arguments as something that are only available in
preparsed, one-at-a-time chunks with no flexibility allowed to the user.

---------------------------------------------------------------------

I wonder where the phrase "least common denominator" came from?  For
positive integers, the number would always be one.

--
J. Giles
Ricercar Software



Thu, 08 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables


[snip]

Quote:
>I want to get the arguments too.  So that if I have a calculator
>program, the command line:

>   calc pi*x/180

>should not return an incorrect list of files "globbed" from the local
>file list, but the result of the expression.  The assumption you are
>making is that what constitutes "the arguments" is defined the same for
>all processes.  That is simply not the case.  It is no trouble at all to

Globbed file list?  I don't want no s{*filter*}kin globbed file list.  :-)  I
want the string (or strings) that appears after my program name.  Those
are the arguments.  My progam will then interpret and act on whatever it
finds, following the orders I gave it.

I also don't expect the OS to pass to my program the calculated value of
pi*x/180.  I might want to use an alternate value of pi.

I just tried a quick test program in MS Fortran that does its getarg on
the first two arguments, then spits it back.  If I enter

test abcd

I get "abcd" back.  If I enter

test 23*a/pi**3

I get "23*a/pi**3" back.  I assume that if I were doing a calculator
program, the program would parse all that.

If you have a Unix system whose Fortran has getarg (or equivalent), what
would this example give?

Continuing my test, if I do

test ab cd

I get "ab" and "cd" back.  If I do

test "ab cd"

I get "ab cd"

If I do

test ab >dummy

I get a nice little file named dummy that contains "ab".  The
enclose-in-"" trick does get me "ab >dummy" or "ab" and ">dummy",
depending where I put the "s.

When I use the getarg (or is it getargc?) function on the SGI machine at
work, it gives me the strings I put on the command line.  Haven't tried
any of the above tricks yet, though.

There is obviously an issue that the OS sees the command line first, and
will apply its rules to it.  But that's something we already live with in
mundane things like how many characters make up a file name, how many
dots, which characters are allowed, etc.

If we agreed that a command line arguments are the strings on the command
line, it seems like that would be useful.  That's what a lot of Fortrans
already do.  There will be characters that different OS's will grab for
themselves, but the OS is the first to the dinner table.

Ken Plotkin



Thu, 08 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables

[...]

Quote:
> Globbed file list?  I don't want no s{*filter*}kin globbed file list.  :-)  I
> want the string (or strings) that appears after my program name.  Those
> are the arguments.  My progam will then interpret and act on whatever it
> finds, following the orders I gave it.

I agree with that (to an extent), however, you can't get it on a UNIX
system.  What's done to the command line depends on the shell (or
command interpreter) that you are using, and various settings.  Not on
how you intend to use the data or anything you might do within your
program.

[... example with calc pi*x/180 ...]

Quote:
> I also don't expect the OS to pass to my program the calculated value of
> pi*x/180.  I might want to use an alternate value of pi.

Same here.  I want my calc tool to receive the string 'pi*x/180' as the
command line image (or, the five tokens: 'pi', '*', 'x', '/', and
'180').  UNIX won't give you that.  Usually it will either refuse to run
your program at all (because it finds no local files named '180' in
directories whose names begin with 'pi' and end with 'x') or it will
start your program with a list of arguments consisting of the names that
matched (almost certainly not what I want).  Your program cannot turn
off this behavior.  The end user can turn it off (under *some* shells).
But the user must do this explicitly, and after doing so, the usual UNIX
utilities no longer work as expected - until 'globbing' and other
processing is turned back on.  Bletch!

Let's get back to first principles:  I want the command line to be
passed in such a way that I could (if I wanted to) write an echo utility
which would simply print out the rest of its command line.  So:

=> myecho a*b    "12+34/5" >test <dummy | abc \xyz ~ $A
a*b    "12+34/5" >test <dummy | abc \xyz ~ $A

Note that the echoed string does *NOT* remove quotes, use redirection
symbols, do file name 'globbing', etc.  Not even redundant whitespace is
deleted.  I want to decide for myself whether '>' means redirection of
output, whether * is a filename wildcard, or whether quotes are
significant as part of the data.  I don't want the system to decide, and
I don't want to have to quote or escape any special symbols.  It should
be up to me what the command line means and no one else.  If I then
*choose* to adopt some standard interpretation, I call call the library
function which invokes that interpretation.

Under most UNIX shells, the command is sometimes not even allowed to
run! The following line will cause the shell to issue an error message
if the 'pattern' fails to match any local file names:

(UNIX prompt)=>myecho a*b
No Match.

The shell has taken the responsibility to issue the message and not even
invoke the program.  That's clearly not what I want.

[...]

Quote:
> If we agreed that a command line arguments are the strings on the command
> line, it seems like that would be useful.  [...

I do not agree that the command line arguments are the strings on the
command line.  Which strings?  Your own examples show that some strings
are not even passed through to the program (those with '>' before them
for example).  Some strings are altered on the way ('a*.txt' turns into
a whole list of argument strings under most UNIX shells).  My calculator
tool wants the strings parsed according to different rules (and no
deletion, insertion, expansion, or interpretation of 'special'
characters).

No, the command line argument (singular) is the text of the command line
after the command name itself.  What the program does with that, and
whether it chooses to interpret it as one or many strings should be up
to the author of the program.

Why not have a command line facility which allows the programmer to
control how (or if) these activities are done?  The default could be
exactly the same as what you're presently used to (if that's what you
want).  Indeed, you could set your own defaults in your version of the
command line MODULE, and then just include it without any additional
thought.

Quote:
> ...]     There will be characters that different OS's will grab for
> themselves, but the OS is the first to the dinner table.

That's exactly what I object to.  And it is not something I want to have
the Fortran standard officially recognize or condone.  Further, OS's
didn't used to do this.  Good ones still don't.  As I've said before,
this issue cannot be resolved within the context of the language
definition - it should NOT be specified there.

In any case, the issue is becomming obsolescent.  I never use command
lines under windows (neither X, nor MicroSoft).  Indeed, my Visual C++
doesn't even support the command line (at least, there is no
documentation of its presence or use).  I can't decipher how to pass a
command argument through a mouse click anyway.  In addition, I seldom
write programs which use command lines on UNIX, even for text-based
programs: too much uncertainty about how different shells parse the
input.  It's simply better to communicate the data through a channel I
have control over.  At least that way I can document unambiguously.  Why
standardize something that's on its way out?  Especially since there is
obviously considerable disagreement over what it should look like.

--
J. Giles
Ricercar Software



Thu, 08 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables

[...]

Quote:
> Getting command line arguments is a feature that is available in so many
> Fortrans.  So many people ask about it that it has its own FAQ.  Why is
> the "standards" committee so neutral about whether it should be officially
> included?

The problem is that what most Fortran users want from the feature is not
possible under UNIX operating systems: to get the whole, unparsed
command line.  This convinces others on the committee that the feature
is so system dependent that it is outside the scope of the language
standard.  To specify a minimal version of the feature which works on
most systems is not acceptable since it might limit availability of
better functionality on systems which are otherwise capable of providing
it.

--
J. Giles
Ricercar Software



Thu, 08 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables

I would endorse getting the whole command line. Splitting into tokens
is problematic at best. Limiting arguments to file names seems a bit
silly; why do operating system designers think they know what a program
is going to do?



Thu, 08 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables

Quote:


> [snip]
> >I want to get the arguments too.  So that if I have a calculator
> >program, the command line:

> >   calc pi*x/180

> >should not return an incorrect list of files "globbed" from the local
> >file list, but the result of the expression.  The assumption you are
> >making is that what constitutes "the arguments" is defined the same for
> >all processes.  That is simply not the case.  It is no trouble at all to

> Globbed file list?  I don't want no s{*filter*}kin globbed file list.  :-)  I
> want the string (or strings) that appears after my program name.  Those
> are the arguments.  

I don't think the intent of getarg() was to allow handing numerical
parameters to the program. If you have numerical constants that
change from run to run. I'd put them in a data file.

I also disagree (strongly) with the assertion earlier in the thread
that most users want the entire line as a mega_string. I wouldn't
know what to do with a mega_string if I got it. All I want is to
pass to the program enough information that it can do what I want.
Usually, that means some file names. e.g.:

        % myprog infile.dat outfil.dat

Far from being difficult or impossible to implement in a unix
environment, this is *precisely* the concept of "filters" which
is axiomatic to the ideology of the unix paradigm.

Right now, there is no standard, and not even a reasonable consensus.
Some getarg() functions have zero-based indexing and some have
one-based indexing. When porting from one system to another, hacking
the code that handles the command line arguments from the convention
of the last compiler to the convention of the new compiler is one
of *THE* most common, most time consuming, most frustrating, least
productive and least necessary parts of the conversion.

Every version of the standard has included specification (in
excruciating detail), for behavior of other, far-less-commonly-used
corners of the langauge, than what Ken is proposing here.

It's easy to second-guess a committee decision, so I hate to do
it. But I think this one is sufficiently far from the mark that
it needs reevaluated. I think Ken has the high road on this one.

--
Glen Clark

State College, PA



Fri, 09 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables


[snip]

Quote:
>I do not agree that the command line arguments are the strings on the
>command line.  Which strings?  Your own examples show that some strings
>are not even passed through to the program (those with '>' before them
>for example).  Some strings are altered on the way ('a*.txt' turns into

[snip]

My example of ">" is pretty simple compared to the examples you've given.
The point is pretty much the same, though:  the OS is first to the table,
and eats what it wants.  Unix is awfully aggressive in that regard; it
really blurs the line between OS and application.

[KP]>> themselves, but the OS is the first to the dinner table.

Quote:

>That's exactly what I object to.  And it is not something I want to have
>the Fortran standard officially recognize or condone.  Further, OS's
>didn't used to do this.  Good ones still don't.  As I've said before,
>this issue cannot be resolved within the context of the language

[snip]

It's a shame that a rogue OS can muck things up to the point that a common
feature can't be standardized.  The fact is that many Fortran compilers
(including some on Unix systems) do allow access to the command line.
Many do it almost the same.  People like me who try to move code among
systems have to change stuff to match the individual compiler.  That's the
kind of thing that standardization is supposed to help us out with.  I
don't like not having anything because it's impossible to provide
everything.

BTW, command line arguments are not on their way out.  They're alive and
well in Windows 95.  I've been making use of them to have separate desktop
icons for different modes of the same program.  Command line arguments and
environment variables (the other half of this discussion) are neat ways to
let a user configure a program.

Ken Plotkin



Fri, 09 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables



: >
: > [snip]
: > >The problem is that what most Fortran users want from the feature is not
: > >possible under UNIX operating systems: to get the whole, unparsed
: > >command line.  This convinces others on the committee that the feature
: > [snip]

Nope. I am quite happy to let the shell construct the argv list, and I
don't want any mongo-huge string. _If_ I did want such a string, I would
quote it, like all sane sencible people do. After all, why would I want
to have a program different in behaviour to all the other utils on Unix
boxes? I mean, it not very _standard_ to do something completely different
now is it ..... :)

: Not only are the parsing rules sometimes different from one program to
: another, but so are the interpretations of the token even when the same
: parse is used.

:    ls aa*

: This should list the local files whose names begin with 'aa'.

:    rls machine-name aa*

Ah! But what if I want to see if a local file begining with aa is
on the remote machine? The inconsistancy is rather unworkable, so
it seems to me.

--

School of Maths, UNSW, Sydney 2052              +(61 2) 9385-3009



Fri, 09 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables


: Let's get back to first principles:  I want the command line to be
: passed in such a way that I could (if I wanted to) write an echo utility
: which would simply print out the rest of its command line.  So:

: => myecho a*b    "12+34/5" >test <dummy | abc \xyz ~ $A
: a*b    "12+34/5" >test <dummy | abc \xyz ~ $A

: Note that the echoed string does *NOT* remove quotes, use redirection
: symbols, do file name 'globbing', etc.  Not even redundant whitespace is
: deleted.  I want to decide for myself whether '>' means redirection of
: output, whether * is a filename wildcard, or whether quotes are
: significant as part of the data.

What happens when somone trys to use your echo utility and wants to pipe
its output to a file? the loss of functionality compared with

 => echo 'a*b    "12+34/5" >test <dummy | abc \xyz ~ $A
    a*b    "12+34/5" >test <dummy | abc \xyz ~ $A'

seems minimal.

: In any case, the issue is becomming obsolescent.  I never use command
: lines under windows (neither X, nor MicroSoft).  Indeed, my Visual C++
: doesn't even support the command line (at least, there is no
: documentation of its presence or use).  I can't decipher how to pass a
: command argument through a mouse click anyway.  In addition, I seldom
: write programs which use command lines on UNIX, even for text-based
: programs: too much uncertainty about how different shells parse the
: input.  It's simply better to communicate the data through a channel I
: have control over.  At least that way I can document unambiguously.  Why
: standardize something that's on its way out?  Especially since there is
: obviously considerable disagreement over what it should look like.

I really love doing the same operation to 100 files using some GUI
program. To saw that the CLI is even near obsolescence is slightly
overstateing the truth.

--

School of Maths, UNSW, Sydney 2052              +(61 2) 9385-3009



Fri, 09 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables

Quote:



> : >
> : > [snip]
> : > >The problem is that what most Fortran users want from the feature is not
> : > >possible under UNIX operating systems: to get the whole, unparsed
> : > >command line.  This convinces others on the committee that the feature
> : > [snip]

> Nope. I am quite happy to let the shell construct the argv list, and I
> don't want any mongo-huge string. _If_ I did want such a string, I would
> quote it, like all sane sencible people do. After all, why would I want
> to have a program different in behaviour to all the other utils on Unix
> boxes? I mean, it not very _standard_ to do something completely different
> now is it ..... :)

> : Not only are the parsing rules sometimes different from one program to
> : another, but so are the interpretations of the token even when the same
> : parse is used.

> :    ls aa*

> : This should list the local files whose names begin with 'aa'.

> :    rls machine-name aa*

> Ah! But what if I want to see if a local file begining with aa is
> on the remote machine? The inconsistancy is rather unworkable, so
> it seems to me.

> --

> School of Maths, UNSW, Sydney 2052              +(61 2) 9385-3009

--
J. Giles
Ricercar Software


Fri, 09 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables

Quote:

> Nope. I am quite happy to let the shell construct the argv list, and I
> don't want any mongo-huge string. _If_ I did want such a string, I would
> quote it, like all sane sencible people do. [...

I think you are reading incorrect limitations into my proposal.  I
propose that the command line parser be part of a standard library which
*can* return the whole command line or that *can* return the arguments
one at a time.  This later capability could be made to resemble the UNIX
features as closely as you like. Maybe it even *ought* to be made to
resemble the UNIX interface exactly.  You could even set it up so that
calling the UNIX-like interface would, by default, activate all the
redirection and other features you desire.  However, a different
programmer could choose to use a different set of delimiters before the
parse, turn off redirection, turn off pipes, and/or interpret any and
all 'special' characters as s/he sees fit.  And in the extreme you could
get the whole command line intact.

In any case, the system or shell should *never* take it upon itself to
alter or delete any part of the command string in an irrevokable way.
Nor should it refuse to run your program simply because *it* decides the
arguments are inappropriate.

One major reason that I don't like the UNIX rules is that they prohibit
me from being consistent.  As in the example case repeated (once again)
below:

Quote:
> :    ls aa*

> : This should list the local files whose names begin with 'aa'.

> :    rls machine-name aa*

> Ah! But what if I want to see if a local file begining with aa is
> on the remote machine? The inconsistancy is rather unworkable, so
> it seems to me.

That's exactly what I want.  I want the second command to list files
which reside on the remote machine whose names begin with 'aa'.  To that
end, I do NOT want the filename specification "globbed" locally - I want
it "globbed" remotely.  The third example (which you elided) should not
"glob" the arguments at all.  I want it to use the same wildcard syntax
as "globbing", but on a database consisting of telephone listings.  In
short, the question of whether the 'aa*' string is a pattern and if so,
what text should it be matched against is *not* known by the shell and
should be decided by the application.

Quote:
> : Let's get back to first principles:  I want the command line to be
> : passed in such a way that I could (if I wanted to) write an echo utility
> : which would simply print out the rest of its command line.  So:

> : => myecho a*b    "12+34/5" >test <dummy | abc \xyz ~ $A
> : a*b    "12+34/5" >test <dummy | abc \xyz ~ $A

[...]

Quote:
> What happens when somone trys to use your echo utility and wants to pipe
> its output to a file? the loss of functionality compared with

>  => echo 'a*b    "12+34/5" >test <dummy | abc \xyz ~ $A
>     a*b    "12+34/5" >test <dummy | abc \xyz ~ $A'

> seems minimal.

If I want my echo utility to permit redirection, then I am free to
recognise that part of the UNIX-like syntax.  I should also be free not
to.  Note that the features you support are confusing even to you: since
you quoted the command string incorrectly in your counterexample.  This
is particularly telling since it demonstrates the well known fact that
UNIX's quoting and escaping rules (which vary from shell to shell) are a
large cause of subtle errors.  Under my proposal, you'd rarely have to
quote or escape anything since the application itself knows which
arguments are to be treated in what way and you don't have to exercise
any prior restraint against the shell or system.

[...]

Quote:
> I really love doing the same operation to 100 files using some GUI
> program. To saw that the CLI is even near obsolescence is slightly
> overstateing the truth.

Yes, I like doing that too.  And I can do that, even on systems which
merely pass me the whole command string.  I am free to pattern match
against file names or not, as pleases me.  Utilities which need to
support such wildcarding should be able to do so.  Utilities which are
more natural and useful when given different syntax rules should be
permitted to use such alternative syntax.  The system/shell should *NOT*
decide for me.

But, I would not use command lines for this purpose in a GUI.  The
program would instead be configured to take data directly from the
windowing environment (perhaps by highlighting the files to be processed
in a graphical way, or selecting by wildcard in the file manager and
dragging the result to the icon for my program).  This would eliminate
the need for the windowing tools to generate command lines which would
then need to be parsed back into the required data.

I really don't see what all the controversy is about.  What I propose
permits existing UNIX-like interfaces to operate almost identically to
the way they presently do under UNIX itself.  It prohibits nothing.  But
it also permits more consistent and flexible interfaces to be written
instead, should you choose to do so.  If you don't like the whole
command line, you can choose the variant of the interface which never
presents it.

Of course, the question is moot (in this forum anyway) since UNIX works
the way it does and there's no changing that.  Therefore, the Fortran
standard cannot specify a satisfactory command line feature.  Therefore,
the only place to put such a feature is in a supplimentary standard.
This is what I've maintained all along.  By all means, standardize a
Fortran interface to UNIX-like command lines.  Just don't clutter the
Fortran standard with it.

--
J. Giles
Ricercar Software



Fri, 09 Jul 1999 03:00:00 GMT  
 Command Line Arguments & Environmental Variables

[...]

Quote:
> -Every week or so in c.l.f, there's a post "How do I
> getarg()/iargc()/getenv() on (name a processor)"  That
> means there's a demand.

Well, every month or so.  And sometimes the answer is that is can't be
done on the system in question.

[...]

Quote:
> -Many GUI's simply construct command lines.  I don't think
> command lines are near extinction.  If iargc()/getarg()/getenv()
> are inappropriate for a particular processor, that processor
> is free to return an error status.

And many GUI's do not construct command lines.  I would isolate those
details if I were writing a code which I wanted to make portable.
Reliance on the existence of command lines in a graphical environment is
just asking for trouble.  If the standard merely says that
iargc()/getarg()/getenv() either work or they don't, in what way is
their presence an enhancement of portability?  You still have to isolate
this in your "system dependent" module which still requires changes on
every port.

[...]

Quote:
> -Fortran is supposed to be a permissive standard where various
> vendors make extensions which may later be subject to standardization.
> Plainly, iargc()/getarg()/getenv() fit that category.  It's
> time to get the spelling straight.  It's _not_ clutter.
> It's a portability issue, which should be *in the standard*.

Yes, it's a portability issue.  It this a feature which inherently makes
your programs non-portable.  This has always been the case.  It always
will be - unless the standard *requires* that the parsing of the command
line and taht it's interpretation *must* *not* be performed by the
system or the shell.  And such a requirement is beyond the scope of the
standard, so it won't happen.

Portability is more than just "what do I have to change in the program
to get it to (sort-of) work in the new system?"  That is not even the
most important part of portability.  You only have to worry about that
once each time you move to a new environment.  The more important issue
is "what can I document as the interface and behavior of my program:
what can the end user rely on?"  As long as the system is allowed to
parse and interpret the command line, there is no way for me to portably
document the means by which my program is initialized.  Yet this is
vastly more important than how my program internally obtains the
initialization data.  The end user of my program (often me) doesn't care
how I fetched the command line internally.  All the end user sees is the
documented command syntax (or the lack thereof, since it can't be
described portably).  And that's (mostly) all I care about as well.  

Juggling the internal mechanisms for command lines has always seemed to
me to be a trivial part of the process of programming.  Writing code to
be consistent and reliable is the hard part, and the most important.
Features which promote the latter are to be welcomed into the language.
Features which *enforce* inconsistency and unreliability are inherently
undesirable.

--
J. Giles
Ricercar Software



Fri, 09 Jul 1999 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Command Line Arguments & Environment Variables Proposal

2. Command Line Arguments - Q&A

3. command environments and command line arguments

4. Fortran command to read command line argument?

5. Command line variables to executables,command programs

6. J hack capturing command line arguments

7. Command Line Arguments

8. Command line argument

9. Command line arguments

10. How do you obtain command line arguments?

11. Command line arguments

12. COMMAND LINES ARGUMENTS IN WIN32FOR 3.3

 

 
Powered by phpBB® Forum Software