Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autocomplete package names #75

Closed
jacques- opened this issue Apr 17, 2013 · 5 comments
Closed

Autocomplete package names #75

jacques- opened this issue Apr 17, 2013 · 5 comments
Labels

Comments

@jacques-
Copy link

At startup you could scan all installed packages and then autocomplete package names, bit of a pain re-typing them all the time.

Perhaps provide a way to create aliases for package names so I could do:

p = com.mwr.mercury.agent
app.activity.info -a p

would save loads of time...

@metall0id
Copy link
Contributor

Maybe we can have an implementation where you can set your own "environmental variables" e.g.

mercury> set p="com.mwr.droidhg.agent"
mercury> run app.activity.info -a $p

This will also be useful to make a cleaner implementation of the dirty replace() used for $BB in shell.py

I was also looking to provide a helper module for SQLITE3 that allows you to type $sqlite in a shell and have that binary referenced like busybox. Implementing this functionality would allow it to be cleanly integrated without adding another dirty replace() for it

@metall0id
Copy link
Contributor

Or something that conforms more to the rest of the Mercury UI like:

mercury> set p com.mwr.droidhg.agent

and then have the following command to remove it:

mercury> unset p

@ghost
Copy link

ghost commented Apr 17, 2013

I think this is two separate features. I like the idea of being able to set and unset variables (maybe with an alias to export to keep the linux folks happy), but auto-completing package names would also be very handy.

@metall0id
Copy link
Contributor

Agreed, two separate features. Maybe we can keep these variables in the .mercury_config and when running the setup modules like busybox then it registers the appropriate variable automatically

@metall0id
Copy link
Contributor

The use of these variables may not be the best idea. Having uploaded binaries like busybox directly on the path for each Mercury shell as described in #81 seems like a better way to go.

ghost pushed a commit that referenced this issue Apr 25, 2013
…of these with various commands before they are executed; refs #75
ghost pushed a commit that referenced this issue Apr 25, 2013
…iables and to view what will be executed once a command has been pre-processed; refs #75
ghost pushed a commit that referenced this issue Apr 25, 2013
… working directory) and /home/dbradberry/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/share/android/ndk:/usr/local/share/android/sdk/platform-tools:/usr/local/share/android/sdk/tools:/home/dbradberry/.rvm/bin:/home/dbradberry/Documents/projects/mercury/workspace/mercury/bin (the system path, including our bin folder); refs #75
ghost pushed a commit that referenced this issue Apr 26, 2013
…, overwriting any default variables we may have already set; refs #75
ghost pushed a commit that referenced this issue Apr 26, 2013
…gument so we can access more of its members; refs #75
ghost pushed a commit that referenced this issue Apr 26, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants