Re: symbolic links, aliases, cls clear

2006-03-30 Thread Michael Paoli
mp wrote:
> i have a python program which attempts to call 'cls' but fails:
> sh: line 1: cls: command not found
> i'm using os x.

[Note Followup-to: severely trimmed]

I'd guestimate (those more familiar with python can probably fill in
more relevant python specific details) that the python program is
probably doing something like:
system("cls")
... or whatever the python-specific way of writing something like that
is.  Most likely that was written, intended for some Microsoft
DOS/Windows/XP or similar type of operating system - where CLS is a
legitimate command (to clear the screen).  On UNIX (and probably also
OS X), there is no "cls" as a standard command, but there is the quite
standard command "clear", to clear the "terminal" screen.

In the land of UNIX, most languages implement the system() function or
equivalent, by typically fork(2)ing and exec(3)ing (at least one of the
exec(3) family of calls), generally invoking "the" or a default shell
(typically /bin/sh) with a first option argument of "-c", and then the
argument to system passed as one single string as the other argument to
the shell.  It would seem likely that python was "smart enough" (of
course) to know on UNIX to implement system() as sh -c ..., rather than
something like COMMAND /C ... or CMD /C ... as it would likely do on
DOS/Windows/XP or similar.  But "of course" python probably has no clue
what the cls is that's handed to it with system(), and likely just
blindly passes it on to the shell.  The diagnostic you got would also
seem to imply that's what happened (the shell (sh) couldn't find the
cls command). ... as a matter of fact, if I try that on Debian
GNU/Linux 3.1 (technically not "UNIX", but neither is OS X, but for
practical purposes they're both quite sufficiently close), I get
results that would appear exceedingly consistent with the hypothesis I
put forth:
$ sh -c cls
sh: line 1: cls: command not found

If it's desired to have the python program function as close to its
(apparent) original intent as feasible, it may be desirable to:
have it test the operating system, and if it is UNIX or similar, use
clear, instead of cls ... or if one wants to port/adapt it to UNIX
(and OS X, etc.), with no need or intention to move it back and forth
or among significantly different operating systems, then perhaps
consider simply replacing the system(cls) with system(clear), or
whatever the precise suitable change in the python code would be.
It would probably also be worth inspecting the code for other
occurrences of system() that may also need to be adjusted or changed.

Note also that some languages (e.g. Perl) will potentially take
shortcuts with the system() function.  For example, with Perl
(paraphrasing and perhaps over-simplifying a bit) if Perl sees no
need or reason to have to use the overhead of the shell to invoke the
system() function, it will just quite directly (after the fork(2))
exec(3) the command, setting the argument(s) suitably.  Python may
(or may not) try similar shortcuts.  For example, CLS, on DOS, etc.,
is internal to the "shell" (command interpreter), so, if python
didn't find an external CLS command, it would have to pass it to the
"shell", hoping the shell would know what to do with it.  That would
happen to work with DOS, but would generally fail on UNIX (where cls
would generally not exist as a command, and wouldn't be built-in to
the shell).

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: symbolic links, aliases, cls clear

2006-04-12 Thread Michael Paoli
Floyd L. Davidson wrote:
> [EMAIL PROTECTED] wrote:
> >If I may recommend an alternative,
> >print "\033[H\033[J"
> Unfortunately, it is poor practice to hard code such sequences.
> Instead the proper sequence should be obtained from the
> appropriate database (TERMINFO or TERMCAP), and the easy way to
> do that is,
>tput clear

Or clear(1), as also mentioned earlier.  Yes, definitely don't want to
hardcode the sequence.  Definitely do use the appropriate terminal
capabilities database (terminfo or termcap) in the appropriate manner
(e.g. clear(1) or tput clear will handle that in the simple case of
shell accessible means to clear the screen).

Most UNIX(/LINUX/BSD/...) implementations support a large number of
terminal types.  E.g. on my system, I check and find that there are
1470 unique terminal types (descriptions) supported - and that's not
including multiple aliases for the same terminal type/description (but
it does count distinct names/files which have differing
configurations, even if they are for the same terminal - such as
changing certain options or behavior of a terminal, or using the
terminal in distinct modes).  Among those terminal types on my system,
I find 154 distinct means of clearing the screen.  Just for
illustrative purposes, here are the top 10 I find, with count of how
many distinct types (descriptions) use that particular sequence:
236 clear=\E[H\E[J,
120 clear=^L,
120 clear=\E[H\E[2J,
 64 clear=\EH\EJ,
 61 clear=\E[2J,
 42 clear=\E[H\E[J$<156>,
 38 clear=^Z,
 36 clear=\E[H\E[J$<50>,
 31 clear=\E[H\E[J$<40>,
 29 clear=\E[2J\E[H,
And of course, sending the wrong sequence (e.g. like trying some to
see what works) can be highly problematic - it can do very nasty
things to some terminals.  E.g. I own one terminal, which among
sequences it supports, is one which effectively says interpret the
following hexadecimal character pairs as bytes, load them into RAM,
and execute them - a relatively sure-fire way to crash the terminal if
it is sent garbage (I used to run into that and other problems with
some BBS systems that would presume everyone must be running something
ANSI capable or that it was safe to do other tests such as see if
certain sequences would render a blue square on one's screen).

references:
"system" call/function, in various programming languages
clear(1)
tput(1)
terminfo(5)
termcap(5)
news:[EMAIL PROTECTED]
news:[EMAIL PROTECTED]

-- 
http://mail.python.org/mailman/listinfo/python-list