[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


   -------Original Message-------
   > 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.
E.g.,
   >  >> 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.

   >  
   >  [snip]
   >  
   >      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.

    --dang




More information about the IPython-user mailing list