I have some of the console commands I would like to use from Emacs, namely ag. It works great in CMD or Far Manager. However when I use it from Emacs shell or eshell I run into a problem which may be (slight chance, though) ag-specific.
When I run shell and then run ag it returns result (help screen) immediately. If I run it searching for a line in files inside directory as ag needle, it hangs and doesn't return anything.
If I run it as ag needle . it returns result immediately, however missing file names and lines numbers, --color and -nogroup options do not affect the printed result in this case.
When I run it via shell-command it returns the correct result (with file names and line numbers). eshell has the same problem.
What do I need to do to make these commands work in shell and/or eshell ?
It's been noted in the answers to this question that Win32 has issues with subprocess buffering. Is there a way to fix it?
Related
I want to send commands in the ADB shell itself as if i had done the following in cmd.
>adb shell
shell#:/ <command>
I am using python 3.4 on a windows 7 OS 64bit machine. I can send one-line shell commands simply using subprocess.getoutput such as:
subprocess.getoutput ('adb pull /storage/sdcard0/file.txt')
as long as the adb commands themselves are recognized by ADB specifically, such as pull and push, however there are other commands such as grep that need to be run IN the shell, like above, since they are not recognized by adb. for example, the following line will not work:
subprocess.getoutput ('adb shell ls -l | grep ...')
To enter the commands in the shell I thought I needed some kind of expect library as that is what 'everyone' suggests, however pexpect, wexpect, and winexpect all failed to work. they were written for python 2 and after being ported to python 3 and my going through the .py files by hand, even those tweaked for windows, nothing was working - each of them for different reasons.
how can i send the input i want to the adb shell directly?
If none of the already recommended shortcuts work for you you can still go the 'regular' way using 'subprocess.Popen' for entering commands in the adb shell with Popen:
cmd1 = 'adb shell'
cmd2 = 'ls -l | grep ...'
p = subprocess.Popen(cmd1.split(), stdin=PIPE)
time.sleep(1)
p.stdin.write(cmd2.encode('utf-8'))
p.stdin.write('\n'.encode('utf-8'))
p.stdin.flush()
time.sleep(3)
p.kill()
Some things to remember:
even though you import subprocess you still need to invoke subprocess.Popen
sending cmd1 as a string or as items in a list should work too but '.split()' does the trick and is easier on the eyes
since you only specidfied you want to enter input to the shell you only need stdin=PIPE. stdout would only be necessary if you wanted to receive output from the shell
time.sleep(1) isn't really necessary, however since many complained about input issues being faster or slower in python 2 vs 3 consider maybe using it. 'they' might have been using versions of 'expect' that need the shell's reply first. this code also worked when i tested it with simply swapping out and in the process with time.sleep(0)
stdin.write will return an error if the input is not encoded properly. python's default is unicode. entering by binary did not work for me in my tests like this "b\ls ..." but .encode() worked. dont forget the endline!
if you use .encode() there is a worry that the line might not get sent properly, so to be sure it might be good to include a flush().
time.sleep(3) is completely uneccesary, but if your command takes a long time to execute (eg a regressive search through the entire device piped out to a txt file on the memory card) maybe give it some extra time before killing anyhting.
remember to kill. if you didnt kill it, the pipe may remain open, and even after exiting the test app on the console the next commend still went to the shell even though the prompt appearsed to be my regular cmd prompt.
Amichai, I have to start with pointing out that your own "solution" is pretty awful. And your explanation makes it even worse. Doing all those unnecessary things just because you do not understand how shell (here I mean your PC's OS shell, not adb) command parsing works.
When all you needed was just this one command:
subprocess.check_output(['adb', 'shell', 'ls /storage/sdcard0 | grep ...']).decode('utf-8')
I often have need of a shell while using Emacs. Recently, I have been trying to switch over from shell to eshell, so that I will be able to use the same commands regardless of platform.
One of the first things I would like to do is customize my prompt to match my bash prompt. To do this, I am customizing eshell-prompt-function. The only thing I am still missing is the current command count and the last return code. I can do this in bash by setting PS1 to e.g. \! and $? respectively. I have already tried (eshell/echo "$?") for the latter, but it doesn't work (though it works if I execute the command manually in eshell).
Edit:
An example of what part of my current bash prompt looks like is [~][501:0], where 501 is the current command number (so if I type a command and hit Enter it will show 502), and the 0 is the return code.
This puts the return code into the eshell prompt:
(setq eshell-prompt-function
(lambda ()
(format "[%s][%s] "
(abbreviate-file-name (eshell/pwd))
eshell-last-command-status)))
I couldn't find any simple way to put the latest command number into the prompt—and it might be less than useful, since eshell seems to use a ring for command history, so at some point the counter would be stuck at 128, and all the previous prompts would be inaccurate.
Note that you should also update eshell-prompt-regexp to match anything that eshell-prompt-function could come up with.
How do I call an emacs lisp function programmatically from an inferior shell?
For instance, I'm in a shell that uses some characters that emacs recognizes and attempts to autoexpand, so I want to run this command (setq comint-input-autoexpand nil) to apply it to the shell I'm in.
I can do this now by entering the text of the command in the shell and running something like eval-region on it but I want my shell to be able to invoke this command itself.
Thanks to the people who responded but it seems my question is unclear. I can accomplish what I want by entering an elisp expression, selecting it, and calling 'eval-region' on it but this requires manual input. What I want is a way to automate this so my shell can send emacs a command to change its own settings.
The "emacsclient" suggestion seems like it's in the right direction but I'm afraid that Windows does not fully support its options and it's unclear that such a command would affect the buffer from which I invoke it since I would do so via an external "shell" command.
What I want is some sort of escape sequence that signals emacs "This elisp expression is for you". I'm guessing there might be a way to open a socket to emacs and send it commands this way but I still have the problem of selecting the buffer to which to apply the command. Again, this is probably more difficult/impossible in Windows, so I will rely on my command bound to a key sequence for now.
It sounds like you are looking for M-x eval-expression, bound by default to M-: (Alt+Colon, i.e. Alt+Shift+semicolon). The expression is evaluated in whatever context you were in when eval-expression was invoked, so if the expression sets a buffer-local variable, it will be set for your current buffer.
You can use emacsclient to do it. You'll need to have started emacs as a server, either with (server-start) in your .emacs or by starting emacs as a background process with --daemon.
You can evaluate elisp code in your shell like this:
emacsclient --eval '(setq comint-input-autoexpand nil)'
I wrote a script that's retrieving the currently run command using $BASH_COMMAND. The script is basically doing some logic to figure out current command and file being opened for each tmux session. Everything works great, except when user runs a piped command (i.e. cat file | less), in which case $BASH_COMMAND only seems to store the first command before the pipe. As a result, instead of showing the command as less[file] (which is the actual program that has the file open), the script outputs it as cat[file].
One alternative I tried using is relying on history 1 instead of $BASH_COMMAND. There are a couple issues with this alternative as well. First, it does not auto-expand aliases, like $BASH_COMMAND does, which in some cases could cause the script to get confused (for example, if I tell it to ignore ls, but use ll instead (mapped to ls -l), the script will not ignore the command, processing it anyway), and including extra conditionals for each alias doesn't seem like a clean solution. The second problem is that I'm using HISTIGNORE to filter out some common commands, which I still want the script to be aware of, using history will just make the script ignore the last command unless it's tracked by history.
I also tried using ${#PIPESTATUS[#]} to see if the array length is 1 (no pipes) or higher (pipes used, in which case I would retrieve the history instead), but it seems to always only be aware of 1 command as well.
Is anyone aware of other alternatives that could work for me (such as another variable that would store $BASH_COMMAND for the other subcalls that are to be executed after the current subcall is complete, or some way to be aware if the pipe was used in the last command)?
i think that you will need to change a bit your implementation and use "history" command to get it to work. Also, use the command "alias" to check all of the configured alias.. the command "which" to check if the command is actually stored in any PATH dir. good luck
Is there a way to run a shell command, have the output show up in a new buffer and have that output show up incrementally? Eshell and other emacs terminal emulators do a find job of this but I see no way to script them.
What I'd like to do is write little elisp functions to do stuff like run unit tests, etc. and watch the output trickle into a buffer.
The elisp function shell-command is close to what I want but it shows all the output at once when the process finishes.
As doublep mentioned, there is M-x compile, and there's also just the simple M-x shell and in that shell you run whatever you want.
You can also use comint-run to execute a command without needing to start a sub-shell first. I believe M-x shell uses comint mode with some modifications, so this won't be a whole lot different from that. But if you want to call a program directly and have its input and output be tied to a buffer, comint-run is the function to call. It is a little tricky to use, so read the documentation: C-h f comint-run.