See sys.argv at http://docs.python.org/library/sys.html
Cheers.
Mark Lawrence.
sys.argv is a list of all arguments from the command line. However,
you'll rarely deal with it directly, there's various modules that deal
with handling arguments. I believe the current one is argparse:
http://docs.python.org/library/argparse.html#module-argparse
Hugo
$hg commit "This is a commit name"
['C:\\hg.py', 'commit', 'This is a commit name']
--
Bob Gailer
919-636-4239
Chapel Hill NC
> Mercurial is written in Python. I know that commit is a function
> that
> commits to a repo, but what command does the program use in order to
> get the
> commit name, like "This is a commit name" (This would make a commit
> with
> "This is a commit name" as the commit name)
Take a look at the Talking to the User topic in my tutorial which has
a section on reading command line arguments.
Interestingly, most of the queries I get on that section are from GUI
users
who don't understand the concept of command line arguments! :-)
--
Alan Gauld
Author of the Learn to Program web site
http://www.alan-g.me.uk/
> sys.argv is a list of all arguments from the command line ...
Interesting that Python didn’t bother to mimic the underlying POSIX
convention of passing the command line as arguments to the mainline routine.
I always felt it was more useful to have command arguments directly
accessible as globals, rather than having to pass them from the mainline.
There *is* no mainline routine in Python.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
> In message <mailman.501.12837893...@python.org>, Hugo
> Arts wrote:
>
>> sys.argv is a list of all arguments from the command line ...
>
> Interesting that Python didn’t bother to mimic the underlying POSIX
> convention of passing the command line as arguments to the mainline
> routine.
What mainline routine?
> I always felt it was more useful to have command arguments directly
> accessible as globals, rather than having to pass them from the
> mainline.
http://c2.com/cgi/wiki?GlobalVariablesAreBad
That's why we have namespaces. If you need the command line arguments,
you just import sys and you have access to them.
--
Steven
> None of them have command line arguments "passed" in to some
> starting point -- all had to use some runtime library function to ask
> for the command line contents.
It’s always a language-specific routine, since at the underlying POSIX level
(exposed by C), the command line is passed as arguments to the mainline
routine.
> On Thu, 09 Sep 2010 12:38:04 +1200, Lawrence D'Oliveiro
> <l...@geek-central.gen.new_zealand> declaimed the following in
> gmane.comp.python.general:
>
>> In message <mailman.501.12837893...@python.org>, Hugo
>> Arts wrote:
>>
>> > sys.argv is a list of all arguments from the command line ...
>>
>> Interesting that Python didn’t bother to mimic the underlying POSIX
>> convention of passing the command line as arguments to the mainline
>> routine.
>>
> What "mainline routine"... The only programming language(s) I've
> ever used that requires there be something called "main" in order to
> start a program is the C/C++ family.
>
Java uses a method defined as "public static void main(String[] args)"
> My college COBOL never used multifile assignments, so I'm not sure
> if there was a difference between main and linked modules.
>
There isn't, but command line argument passing is implementation-
dependent and is complicated by the ability to define callable sub-
programs in the same source file as the main program. The most general
method is to use ACCEPT statements. MicroFocus COBOL uses "ACCEPT ...
FROM ARGUMENT-NUMBER", AIX COBOL uses a special system call and ICL 2900
COBOL and IBM COBOL/400, where the command line uses function call
notation, map the command line arguments into a LINKAGE SECTION.
In short: this area of COBOL is a mess.
PL/I specifies the main procedure with an OPTIONS(MAIN) clause and
declares the integer ARGC_ and pointer ARGV_ variables in it, which are
used like their C equivalents.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
> On Thu, 09 Sep 2010 12:38:04 +1200, Lawrence D'Oliveiro
> <l...@geek-central.gen.new_zealand> declaimed the following in
> gmane.comp.python.general:
>
>> In message <mailman.501.12837893...@python.org>, Hugo
>> Arts wrote:
>>
>> > sys.argv is a list of all arguments from the command line ...
>>
>> Interesting that Python didn’t bother to mimic the underlying POSIX
>> convention of passing the command line as arguments to the mainline
>> routine.
>>
> What "mainline routine"... The only programming language(s) I've
> ever used that requires there be something called "main" in order to
> start a program is the C/C++ family.
[ ... ]
> My college COBOL never used multifile assignments, so I'm not sure
> if there was a difference between main and linked modules.
Historical COBOL had a PROCEDURE DIVISION which marked the start of
execution. But historical COBOL didn't pass parameters anyway. You read
your optional arguments from a file, or accepted a few from an input device.
I don't know PL/I generally, but with Multics PL/I any externally accessible
procedure could be called from the command line:
any_program$ea_proc a b c
passing (for example) 'a', 'b', and 'c' as parameters. If the parameters
were declared as variable-length character strings:
ea_proc: proc (x, y, z);
dcl (x, y, z) char (*);
...
this would even work. Illustrating that the command-line-parameter-passing
question is a deal with the operating system at least as much as it's a
language issue. Posix aren't the only O/S.
Mel.
> FORTRAN just differentiates by having the main file start with
> PROGRAM random_name
> whereas subfiles are all either (or both)
> SUBROUTINE another_name(args)
> FUNCTION that_other_name(args)
no BLOCKDATA?
I think you mean COMMON.
> But historical COBOL didn't pass parameters anyway. You read
> your optional arguments from a file, or accepted a few from an input
> device.
I think it could also read from switches. As in front-panel on/off switches.
i meant BLOCKDATA
BLOCKDATA is an initializer. The actual storage is allocated by COMMON.
> On Fri, 10 Sep 2010 12:25:17 +0200, Giacomo Boffi
> <giacom...@polimi.it> declaimed the following in
> gmane.comp.python.general:
>
> It exists but I've only seen it used once... And I don't recall it
> being "executable" in the same way as program/function/subroutine.
i simply meant that the BLOCKDATA statement can begin a subfile as
well as SUBROUTINE or FUNCTION
--
Sarò un'ingenua ma continuo a pensarla come prima, anche se
probabilmente i fatti mi smentiscono. -- Francy, in IHC