Is there any way to copy the output printed in the terminal to a file.In my case the commands 'script' , 'tee' and '>>' wont work because i already executed my program and given a large output which am not able to copy from the terminal
Got it.
There is an option in terminal->shell-> Export text As. Which resolved my issue :)
No, you can't intercept a running program's existing filehandles and transparently redirect them elsewhere. Some terminal emulators may support logging; if your terminal has enough scrollback you could copy and paste it (although be careful where you paste it to, if it's voluminous; feeding it to other terminals may result in much of it being lost when the pty buffer fills).
Related
I run calculations on Windows for hours and would like to have the calculation report/log inside the interactive IDLE/shell window be saved to a file at the end by a command.
Would be nice to exit() and close the window too.
As much as I like Linux, this is an Unattended Windows machine, hence, some modules/commands are not available, sadly, and the ability to install other software is limited.
The fact that the developers did not think of a command to save the transactions within the IDLE/shell is surprising.
I know in some environments you can direct the output of a job, like a report to another text file by using the key -o, --o, --output, > to a text file. Surprisingly Python does not support anything like that!
Any help would be appreciated
Thanks
Windows Command Prompt supports stdout redirection and probably stderr redirection. I just tested python -c "print(test)" > F:/dev/tem/out.txt and the print out went to out.txt. Replace -c "print('test') with script.py and the same should happen. Piping stdout of one program to stdin of another might work. You might be able to chain programs with a .bat file. PowerShell likely is more powerful and flexible, but I have never used it.
I am not completely clear on what you are asking, but I hope the following answers your questions.
Python runs in 2 modes: batch and interactive. Interactive mode is intended for ephermeral interaction with a human. Batch mode is for unattended computation, with occasional screen messages, but with most results sent to a file other than the screen. Both modes are combined when you run python -i xyz.py. The file is first run in batch mode, and then Python shifts to interactive mode.
It sounds like you should be using batch mode rather than either Python's or IDLE's interactive mode. If your code runs from IDLE, you should be able to run it directly with the same python.exe that you used to run IDLE. There are exceptions, of course, if one makes one's code dependent on running within IDLE, but this is unlikely to be an accident or to be needed for unattended running.
The IDLE Shell simulates interactive Python. When a file is run from an editor window, IDLE simulates python -i file-being-edited.py, with screen output going to Shell. In either case, an interactive user can save the contents of Shell with the File => Save As menu command. So there is such a command. There are also close window and exit commands and shortcuts.
In IDLE's intended use, as an interactive python learning and program development environment, there is no need from for a program to issue these commands. To save data in a file, a program can open a file and write data directly.
Try to see if you can install Jupyter Notebook (not separate software, but just a python module)
pip install jupyter
Jupyter notebook is highly helpful for saving and sharing your code. It can be used as both a shell and as a script editor.
Whenever I enter a terminal command in vim (e.g., !echo hello), I am momentarily kicked out to view the result of that terminal command and then prompted with Press ENTER or type command to continue. This is a bit jarring. I would like to stay within vim and with the command output printed out at the bottom.
I know vim :read will take the terminal output and actually put it into my buffer, but that is not what I am looking to do. Here is some reading if you are interested in a tangent.
It looks like when I run vim in Screen I get what I am looking for, but I am trying to get this to work with tmux and the stock Mac terminal.
After a ton of research, probably too much, I got it! It looks like vim will send commands to the terminal, which in turn defines the behavior of how the terminal commands are processed from vim. Put this into your .vimrc file:
set t_ti= t_te= " show results from terminal commands within vim!
From what I understand, this just makes sure to send nothing to the terminal, which yields my desired results!
Side note: the above addition to your .vimrc file will also prevent the vim buffer from clearing when exiting vim (e.g., :wq). I am okay with this! It is kind of nice sometimes to see what you were just working on :).
I always use Emacs's shell. I create 2 buffers (C-x 2) and use one of them as a terminal (M-x shell).
Sometimes I use a command a lot of times (e. g. python3 test.py). I use shortcut <C-up> to repeat the last command. And it's very inconvenient that Emacs saves duplicates of commands. I have to press <C-up> many times so that I can run any other command.
The problems is only in Emacs's shell. I have setting HISTCONTROL=ignoreboth in .bashrc and in usual terminal it works very well.
Is it possible to configure Emacs so that it ignores duplicates?
It's customizable
(setq comint-input-ignoredups t)
Setting 'comint-input-ignoredups' as suggested by Jürgen Hötzel will of course solve the immediate, but here are some alternatives.
You could choose to use the command 'ansi-term' instead of 'shell', this will run a bash (or whatever you choose) so you get the same control as in (say) an xterm. As an added bonus, you also get a rather capable terminal so applications that depend on this will work.
Another possibility, if you have something you want to repeatedly run, is to use the 'compile' command. This can run any shell command, it does not have to be a compiler. The advantage here is that you keep the running of the test out of your shell command history (no matter how you run your shell) and you get the output in a separate buffer. If the output is suitably organised and/or the compilation buffer is suitably configured, you could also use the 'next-error' command to jump back to the appropriate part of the source.
Finally, I would like to mention that the 'shell' command supports searching the command history. It is by default bound to M-r (comint-history-isearch-backward-regexp).
I tried this just now:
grep -RlI "id=\"kw\"" * | xargs vim
That gave me 16 results. It opened the first result in Vim. I made my very first edit and hit :q since I didn't know the shortcut to jump to the next file.
It threw me back to the console ( I am SSHed in to a server ). My console is messed up now. Anything I type I can't see, and anytime I hit enter it seems like it processes the command but the display/view is screwed up so
[meder#linode] is tabbed in on my console, at least halfway. reset does nothing since it seems to have messed up my real console.
Can anyone offer a solution that doesn't have this same downside? Or can anyone provide an explanation for why :qing out of the very first file messed up my console?
Background information: My PC is Debian Ubuntu, I am SSHed into a RHEL box. The files I opened were text/ascii files phtml/php files and not some weird binary files with crazy characters in them.
Here's a screenshot of what happened
EDIT #1: I just typed reset again and it seemed to work. The first reset did not work I think because somehow the console inserted some whitespaceish character inside it? Anyways, I would like an explanation for this weird behaviour.
Try:
vim -o `grep -RlI "id=\"kw\"" * `
From the man page for xargs:
Undefined behavior may occur if utility reads from the standard input.
That line isn't in the Linux man page but it is present on my Mac. If you want to run a program that you intend to read standard input, the usual linux version of xargs will need an argument to read its input from a file:
OPTIONS
--arg-file=file, -a file
Read items from file instead of standard input.
If you use this option, stdin remains unchanged
when commands are run. Otherwise, stdin is
redirected from /dev/null.
Vim is intended to run with both standard input and standard output connected to real (a very rare case these days) or pseudo tty devices. Wierd things will happen if you upset this arrangement.
The fundamental problem with your command was that, with standard input redirected to the pipe, xargs had no way to run a vim with a "normal" standard input. So the vim mode changes and command input were not what you expected.
You can probably fix this by typing a return, a tilde, and a period. This will force your ssh session closed from your end, you can then ssh in again, and run "ps" to check for anything left hung in the background that you should kill(1).
You can use :next or :n to get to the next file to edit. You can also use vim -o to open up all the matching files in different windows in Vim.
Not sure why your console is messed up though. I tried using your command and my console was fine.
Console options are set by stty, so you may want to save its options to a bash variable and restore them after vim exits, like this:
function vim()
{
STTYOPTS="$(stty --save)"
vim "$#"
stty "${STTYOPTS}"
}
But it is probably the better way to use zsh for this task: if you put the only line ttyctl -f into your ~/.zshrc, then zsh will automatically restore terminal options after program exits. ttyctl is a zsh builtin, so you cannot use it from bash.
Other folks covered what happened and what to do about it. As to why, the answer to that probably lies in what input Vim received from the xargs command and tried to execute as if that input came from a terminal. I don't know how to talk terminal, but you can imagine that Vim got some strange commands that crashed it or told it to quit. Similarly unpredictable things happen when you cat a binary file.
Anway, I have another idea. Have you tried using vimgrep to browse a list of files matching a pattern?
:vimgrep /id="kw"/ *
:copen
This greps for id="kw" in all files in the current directory. :copen opens up a window with a list of matches. You can browse that list, clicking enter to jump to a file position.
For more information, see
:help grep
:help :vimgrep
:help :copen
:help quickfix
If you really need that -I option, see
:help :grep
:help 'grepprg'
See also: Vim: Warning: Input is not from a terminal
Try to use ... | xargs sh -c '...' and then read from the controlling terminal device /dev/tty.
echo ~/.profile ~/.bashrc | xargs sh -c 'vim "$#" </dev/tty' dummy_script_name
# based on a tip by Laszlo Ersek on http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/2010-03/msg00051.html
#find . -maxdepth 1 -type f | xargs sh -c 'rm -i "$#" </dev/tty' dummy_script_name
I used the command tar -x file.tar.gz and, for one reason or anything it failed. Then I get stuck being able to type anything in, but not being able to run any more commands. Pressing enter just gives me a new line. I don't know how to break out of it either (escape etc doesn't work). The only way I can get back working is to close putty and reconnect.
Is there a way to get it back to normal so I can keep going because it's irritating closing it all the time.
Try hitting CTRL+C :) This will cancel/kill/stop the running command!
But the best way to untar is to use -v to verbose the output :
tar -zxvf yourfile.tar.gz
With that, you'll perhaps see that your file just take more time than you thought unarchiving ;)
Ctrl-C can be used to send a break to the executable that's hanging, but it's up to the application to handle it. Ctrl-Z will break you out of the running executable, but you'll need to then manually kill the process.
What you're doing wrong is you're not gunzipping the archive.
Try this
tar -zxf file.tar.gz
If you want to quit it, press CTRL+c.
If you want to keep it but being able to write more commands while it's working, press CTRL+z and bg.
Then it will work in the background.
Your command failed because it is trying to read stdin. This is because you never told it the name of the tar file with an "f" option.
A good Idea would be to use GNU screen. That way, when a command hangs, you can open another screen and take a look at the system (e.g. top to see if tar is still working) or you could kill the process by pressing (strg+a) + k to hard-kill the running process within the screen-session.
Screen also has the nice feature that your processes keep running even though your SSH-connection died. It's a lifesaver!
Your tar invocation is waiting for input on the command line as the others pointed out. You may also use Ctrl-D to indicate EOF to the tar process.