Advanced shell - shellista
<u><b>Commands and features:</b></u><ul>
<li>cd - change directory</li>
<li>pwd - print current working directory</li>
<li>ls - list directory contents (and file sizes)</li>
<li>cat - print the contents of a file</li>
<li>q/quit/exit/logoff/logout - exit the shell</li>
<li>mkdir - make a directory</li>
<li>mv - move or rename files / directories</li>
<li>cp - copy files / directories (recursively)</li>
<li>rm - delete files / directories (recursively)</li>
<li><b>unzip</b> - unzip zip archives</li>
<li><b>untar</b> - untar tar archives</li>
<li><b>ungzip / gunzip</b> - ungzip gzipped files</li>
<li>Supports <b>wildcard matches</b> (matching any number of characters)</li>
<li>Supports <b>? / question mark matches</b> (matching exactly one of any character)</li>
<li>Supports <b>[ranges]</b> (like [a-z], [0-9], [a-f0-9], etc.)</li>
<li>Supports <b>~ / tilde replacement</b> (defaults to Documents folder)</li>
<li>Supports <b>environment variables</b> ($HOME, but you can expand it)</li>
<li>Supports <b>single quote escaping</b> (special characters are disabled)</li>
<li>Supports <b>backslash escaping</b> (for individual special characters)</li>
<li>Supports <b>double quotes</b> (for preserving spaces, but allowing special sequences)</li></ul>
<u>Examples of advanced usage:</u>
<b>ls .py /.py</b> (lists all .py files in current directory and at the top level of any folders in current directory)
<b>cp ~/.py backup</b> (copies all python scripts in the root scripts directory to a folder named 'backup')
<b>rm test[1-3]?.txt</b> (removes files test1a.txt, test2a.txt, test2b.txt, test2c.txt, test3-.txt, etc.)
This is an intial (rough) port of a script I put together for another python interpreter on the app store. I'll be porting the rest of the commands soon: unzip, ungzip, untar, wget/curl (basic download functionality)
<b>For the interested programmer:</b>
This script uses a pure python re-implementation of some of the more basic globbing of "bash" which I wrote up myself. It's a little different than shlex, glob, or shlex+glob in that matching happens in a single parsing run through. It depends on glob for wildcard handling, but only after my code has already handled all character escapes and word parsing.
<u>An example where shlex/glob fails:</u>
In the current working directory are three files: 'test apple', 'peach', 'test a*' (with an asterisk as part of the name)
The command to parse is the string: rm 'test a*' peach
shlex interprets it as ['rm', 'test a*', 'peach'], which glob then interprets the file portion as a match of three files: ['test apple', 'test a*', 'peach']. shlex unfortunately clobbers quotes that in a bash environment specify that the special character should be treated as a literal. This would result in deletion of <b>all 3 files</b>.
With my parser, the single quotes around 'test a*' are interpreted bash-style to mean escaping of the special character '' - disabling it as a wildcard match and turning it into a literal match, resulting in the deletion of only two files: 'test a' and 'peach'.
@briarfox - thanks! I think your modular method is brilliant, and your code and directory structure is very clean. It is implemented just like a "real" shell, in that commands are individual programs - that's how it should be IMHO. I really feel like the way you implemented it is the smart way to go. If you really want to contribute to my repo, create a branch, and make it more like that :).
What I envisioned was somehow taking advantage of the already existing functionality in setuptools to download the plugins and modules -- not sure if this is possible or not. I was going to fork your repo and play around with that when I had a chance. Python isn't my primary language (we are all Microsoft at work), so I'm sure I don't do things the most "Pythonic" way. Suggestions are most definitely welcome.
Regarding installation in site-packages: what do you think the policy should be if the user has that package already in their site-packages? I'm a little worried about overwriting a user's own modules. I keep shellista in a separate subfolder of
~, so that all the dependencies download there; almost like a hackish virtualenv.
@transistor yes I'm (now) using the one from your Git. It is brilliant. Thank you so much. I will give your instructions a go.
BTW here is something stupid I did. I was running shellista -- moving, copying, etc. Then I used pythonista's built in "delete this folder" for a directory that was my current directory in shellista. When I came back to shellista it freaked out (I know, very technical term there) and I basically had to restart pythonista
I don't know if there is a way to fix that/gracefully recover or if it would even be worth it -- probably not a highly likely error and those who do something so silly probably "deserve it." But just thought I'd bring it up.
Transistor.. Your python shell works running files, but you just can't run scenes. Scenes don't execute until after the main script stops running. clock.py is a scene module.
A quick test shows that you can apparently run modules with ui, which opens up lots of possibilities!
@Rothrock42 - You are welcome! I'm really glad it's helpful.
When I tried your scenario, I got a "no such file or directory" error. Is that what you got?
Opened a ticket <a href='https://github.com/transistor1/shellista/issues/9'>here</a>. Will try to take a look at this later tonight (Eastern Standard time)... Right now I am slacking on other things I'm supposed to be doing!
@JonB - that is good to know, thanks!
@transistor1 My thought with using the site-packages for the pypi packages was to allow the user to setup Shellista wherever they like and still have access to the pypi packages in all thier apps. If the module/package already exists we'll try using the one that already there? As for any downloaded code, Id say stick with your download into the shellista folder. I'm working on an easy way to include downloads into the plugins. And have the main shellista use your downloading method on plugin load.
I added you as a collaborator to ShellistaExt. I'll follow your lead on whichever github you want to use as the official Shellista. We could modularize yours and use it or build yours into ShellistaExt. Let me know what you would prefer.
I think Shellista is a must have for pythonista and a easy to empliment plugin system would greatly help on expansion of it.
I added tab completion to transistors repo.
The approach I used was to check for tab at end of line. (Actually, 4 spaces, as tab button produces 4spaces in console, not tabs!). You'd start typing, press tab, then press enter. Ui pops up if needed, you select option, but then since we can't update the console input text, I just print the completion, and you continue entering the line.
Press enter again to execute, or tab-tab-enter to delete the last argument from the working line.
I tried using shellista to clone the latest shellista with the command:
git clone https://github.com/transistor1/shellista.git
I get "No module named config". Is this a known bug or is there more to getting this from the repository?
Try restarting pythonista ... I seem to remember that previously, it would happen during first download, or perhaps if dulwich did not get installed, but it thought it was installed.
Try deleting your dulwich and gittle folders, especially if you had an older version of shellista.
Then, just do copy paste of shellista from github (go to raw) into a new script, maybe in a separate folder, and run it.
Hey there. A new idea for shellista.
You could add a folder ~/bin, where executable programs will be stored (actually python files), so users can add their own commands/programms there.
See the dev-modular branch which has a plugin system.
@pudquick51 This is annoying me extremely as I haven't found an example etc of this. could you please send an example on how to operate this file with a correct directory etc as when I try to use it, it can never find files which exist.
To list a directory, use