After installing ack on Windows 7 64-bit (e.g. using StrawberryPerl), I can run ack from a cmd terminal in Windows.
However, if I try using ack in Emacs in Shell mode (i.e. in a M-x shell buffer), I get not output (all other cmd commands print correctly though).
Interestingly, if I run ack alone - i.e. with no arguments-, I get the ack usage information printed correctly. In other words, ack prints no output in my Emacs shell when I run it with arguments (even though ack should print hits for my queries, as I have checked under cmd).
The lack of output makes me think that ack is waiting for input (although I provide arguments to it). I tried the code snippet suggested here in my .emacs file (which seems to be designed to help ack when it's confused between searching in the file system or STDIN), but the problem still persists.
Any suggestions on how to fix this?
Thanks
ack is waiting on stdin, incorrectly thinking it is in filter mode. As a workaround, add <NUL to the end of the command, closing its stdin.
FYI - Running "ack" in the perl debugger, inside emacs shell on Windows, shows it stopping here:
main::print_matches_in_resource(c:/Strawberry/perl/site/bin/ack:454):
454: while ( <$fh> ) {
Have you checked ack.el?
That's what I use on Windows 7. It makes using ack easier. By default it suggests searching for the word at point. And you get the output through compile, so you can easily jump to the file and line containing the match.
Related
The windows API provides GetCommandLine() which returns the cooked command line used to start a process.
For instance, if a console application is started with the command:
MyProg.exe > OutputHere
The command line seen by MyProg.exe will not include the portion
> OutputHere
I'd like to somehow get the command line exactly as it was. Is this possible ? and if yes, how ?
Suggestions in C and/or plain (no objects) Delphi greatly appreciated. Creative solutions welcome (hopefully, not requiring ring 0 code.)
Thank you very much for your help.
NOTE: I can tell if the input/output, etc has been redirected but, that is not what I'm looking for. I need the original/uncooked command line.
The redirection or piping of stdin, stdout and stderr is handled the command interpreter, typically cmd.exe. The interpreter parses the command and creates the necessary files and pipes, and then creates the one or more processes needed to implement your command.
The processes that are created have no knowledge of the original command, they only get that part of the command that is not related to piping and redirection.
So what you are trying to do is not possible, at least within your process. The only thing that knows the original command is the command interpreter.
Whether or not you can retrieve the full command line including the pipe commands depends on whether your start the program in a command window or for example using the "Run" command from the Start menu. If you use the "Run" command from the Start menu GetCommandLine actually retrieves the full command line including the redirection commands, but redirection does not work as it seems to be a feature of CMD.EXE.
As others have pointed out, what are you trying to achieve here / why do you need to capture the redirection commands?
I used to run cygwin on win8.1, and while giving inputs to a program CTRL-Z used to denote EOF. Today I installed cygwin on win10, and ran "a.out". After typing in the input data, when I press CTRL-Z I get the message "Suspended" and I get back the shell prompt. I tried this with bash and csh, same result. CTRL-D also does not work, it is killing the shell.
Just to confirm that it is only this problem and nothing else, I created a new input.txt file, and entered the relevant input data in it, and ran "a.out < input.txt", and it worked fine. So the problem is only in defining EOF for STDIN.
How to solve this problem?
Note: I am closing this question, and put in more details in a new question reading till EOF in java on cygwin on windows-10
On Unix-like systems, including Cygwin, Ctrl-D is (by default) configured to trigger an end-of-file condition when reading from a tty (terminal/keyboard). It's possible to change this using the stty command, but it looks like you haven't done that (and you almost certainly shouldn't).
If you enter Ctrl-D while running your program that reads from standard input, that will likely terminate your program, depending on how it responds to reaching the end of its input.
Ctrl-Z sends a signal that suspends your current program (some programs, such as interactive shells, are able to handle or ignore that signal). (Windows uses Ctrl-Z to trigger end-of-file.)
The behavior you describe indicates that you're typing Ctrl-D at a shell prompt. This gives the shell, not your program, and end-of-file condition. The shell response to this by terminating (by default; you can use set -o ignoreeof to tell the shell to ignore it).
If you type Ctrl-D while running your program, it should correctly trigger and end-of-file condition and cause your program to terminate.
UPDATE: Normally you should type Ctrl-D either before any other input (resulting in the program receiving no input at all), or immediately after typing Return. To trigger end-of-file in the middle of a line, you'd have to type Ctrl-D twice. (This is usually not a great idea, since it results in the program seeing a partial line with no terminating newline character.)
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?
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')
If I create a process from a cmd prompt using the start command (opening a new cmd) is it possible to redirect the stdout and stderr from that process back to the calling cmd?
If you want the output of the STARTed process to appear in the parent command console, then simply use the START /B option.
If you want to process the output of your command, then you should use FOR /F ... in ('someCommand') DO ... instead.
OK. I have yet to find a straightforward answer to this question. I didn't want to bog down my question with what I thought unnecessary detail but seeing as I'm being criticized for the lack of this I'll expand a bit here.
I want to automate the updating of FWs on our production line, so I've a python app that gets the FWs from ftp and then uses the processors flash tool via python subprocess command to upload it to the board's flash. OK for all but one of the tools.
The one tool seems to have a problem when it's not running in its own terminal, so I provide a start to the subprocess command string which allows it to run OK in its own terminal. However, I need the output from this other terminal for logging reasons.
A possible solution was to log stdout and stderr to file using >> or wintee and then poll this file via a thread in my original app (perhaps a rather convoluted solution to the question). However the tool also has a separate problem where it doesn't like any std redirection, so this doesn't work for me.