[IPython-user] Notes on using ipython as a system shell ('pysh')
Daniel 'Dang' Griffith
pythondev-dang at lazytwinacres.net
Tue Apr 13 08:15:56 CDT 2004
> From: Prabhu Ramachandran <prabhu_r at hathway.com>
> Subject: Re: [IPython-user] Notes on using ipython as a system shell ('pysh')
> Sent: 13 Apr 2004 13:48:57
> >>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
> FP> 4. It should also be possible to expand python
> FP> variables/commands in the
> FP> middle of system commands. I thihk this will make it
> FP> necessary to use $var for name expansions:
> >>> var='hello' # var is a Python variable print var
> FP> hello # This is the result of a Python print command
> >>> echo $var
> FP> hello # This calls the echo command, expanding 'var'.
> Everything else sounds nice. I am not comfortable with '$var'. What
> I would really like to see is that variables are just like any other
> Python variable. Its just that shell commands are part of the
> vocabulary. Or is that hard to implement? For example:
> >> var = 'hello'
> >> echo var + ' world!'
> hello world!
Without a $prefix, I don't see how ipython could tell the difference
between a token the user types in that is intended to be passed
as a literal command argument and one that is to be interpolated
as a python variable. Most of the shells have some kind of quoting
mechanism to indicate whether tokens should be evaluated or left
as literals. Maybe a similar mechanism is needed here.
I'm not adverse to a $prefix. Other shells require something to distinguish
literals from variables. If ipython is a shell, I don't see why it shouldn't
be able to do the same. Python itself doesn't require the prefix
because it has a highly constrained grammar. When you're working
in a system shell, every command could have its own syntax.
To make it appear "pythonic", maybe variables could be wrapped with
the dictionary variable interpolation "%(myvar)s" syntax, using the
shell's globals() as the dictionary. I haven't thought this through
to its conclusion, and I'm not really advocating it, but it is pythonic,
though also a bit perlish.
> >> var = 'hello'
> >> echo %(var)s + ' world!'
> hello world!
Although since the command arguments are always strings, I
don't suppose the trailing "s" in "%(var)s" is needed.
> Also can pipes be handled?
> >> ps uax | grep ipython | sort > /tmp/ps
Yes, I wondered this myself when someone a month or so ago
brought up the shell subject again. I suppose ipython could
parse the line and use popen2/popen3 calls to link the
commands together behind the scenes.
> FP> It should be possible to write code like:
> >>> for ext in ['.jpg','.gif']:
> FP> .. ls file$ext
> How about:
> >> for ext in [...]:
> .. ls file + ext
> Its illegal syntax but its the shell and there are no funny $'s to
> worry about. The trouble with the $ is that it tends to make things a
> little confusing. Without the $, everything is just pure Python with
> shell commands thrown in.
Same response regarding $prefix. I don't think it makes things any
more confusing than working in any other shell. If you say ipython
should try to map every token to an entry in globals() and replace it,
there needs to be a syntax to escape literals. An obvious example
is that in the second above example, 'file' is a built-in type, and is a
python TypeError to combine them with a '+'. This is a case where
a value from the globals() namespace would seep into the syntax.
Of course, 'file' is a simple example, but the point is that there are many
variables in globals() that unexpectedly might interfere with command
invocation. At least in interactive use, I think it unlikely that I will
remember every variable I've created a binding for.
> FP> - it's ok for shell builtins (in this case this includes the
> FP> python language)
> FP> to override system commands on the path. See tcsh's 'time' vs
> FP> '/usr/bin/time'. This settles the 'print' issue and related.
+1. I mentioned the print conflict when this came up, but I completely
agree that the shell should supercede a command in the path, if only
because there are other ways to invoke the command unambiguously.
More information about the IPython-user