Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I'm trying to save stdout of a command to output file output.txt
I can't understand why when I use &> everything is okay and when I use > some strange symbols like [0m[0;1;32m appear randomly throughout the file.
What could cause that?
My investigations shows that these symbols are terminal coloring. But why they disappear when I use &>?
It probably checks whether stderr is connected to a terminal and if it is than it uses color control codes. When you redirect with &> both stdout and stderr are not connected to a terminal, so no colour codes are used.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 days ago.
Improve this question
Why would this bash operation fail to update the file in some cases?
{
flock -x 3
STR="${SLURM_ARRAY_TASK_ID}","${THIS_FILE}"
printf "%s\n" "${STR}" >&3
} 3>>"${WRITTEN_FILE_LIST}"
This command is executed in a script that gets launched concurrently multiple times, and no other operations on this file ever occur.
In the rare cases when it failed:
None of the referenced variables were empty (SLURM_ARRAY_TASK_ID is an integer, THIS_FILE is a short string, STR is a short string, and WRITTEN_FILE_LIST is a short string).
WRITTEN_FILE_LIST is a valid file path to a CSV.
Most of the other processes were able to update the file.
The process reached this block without error.
I only know it failed because the entries were missing from the file.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
Is there any way to filter out absolutely useless messages in bash session by default?
For example, I would like to never see this absolutely useless message: Binary file ... matches while running grep .... It's extremely hard to type something like grep ... 2>/dev/null each time, especially considering how often I need to run this command. Besides it will filter out useful messages as well and this is unwanted.
What I would like to see, is some sort of file in /etc where I could put a bunch of regular expressions of the useless messages line by line. This filter must apply to tty only, i.e. redirected output must stay untouched!
There are some ways to play with your stderr, but there are a number of issues that make that undesirable. For example:
exec 2>/tmp/errorfile
will put all the STDERR output in the errorfile. You could start a
tail -f /tmp/errorfile | grep -v 'Binary file' &
in your .bashrc to get the other messages as well. You will see some funny side effects; for example I found that the prompt is written on STDERR.
You will probably have to create a more elaborate command than the tail|grep to filter-out the undesirable messages and do something about your prompt as well. And you might need to clean-up your errorfile as well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I'm running a script on terminal and it is supposed to produce a long output, but for some reason the terminal is just showing me the end of the result and I cannot scroll up to see the complete result. Is there a way to save all the terminal instructions and results until I type clear.
The script I'm using has a loop so I need to add the output of the loop if Ill be redirecting the output to a file.
Depending on your system, the size of the terminal buffer may be fixed and hence you may not be able to scroll far enough to see the full output.
A good alternative would be to output your program/script to a text file using:
user#terminal # ./nameofprogram > text_file.txt
Otherwise you will have to find a way to increase the number of lines. In some terminal applications you can go to edit>profiles>edit>scrolling tab and adjust your settings.
You can either redirect the output of your script in a file:
script > file
(Be careful to choose a file that does not exist otherwise the content will be erased)
Or you can buffer the output with less:
script | less
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am using Arch Linux arm on a Raspberry Pi model B to create a small streaming solution, where the Pi is permanently connected to a TV.
Using the 'livestreamer' package, I can stream videos and pipe them to 'omxplayer'
This is the command I run in bash:
$ livestreamer https://www.youtube.com/watch?v=7EKkAy-PfN4 best -np "omxplayer -b -o hdmi"
The 'best' argument specifies to stream the video in best quality. '-np' creates a named pipe to the video player. This is necessary as simply using '-p' for a non-named pipe does not work. The '"omxplayer -b -o hdmi"' specifies to use omxplayer to play the video stream, to black the background of the video so the terminal does not show and to use hdmi for the audio output.
The problem I am having is that when the stream is completed, the terminal is left in a state where I am unable to see the commands I type but I can still execute them. The terminal resembles the state which is normally found when entering a password where the typed character cannot be seen.
This only occurs when the stream ends and the program ends itself. If the program is interrupted by the keyboard with Ctrl-C then the terminal remains normal.
Using omxplayer on its own does not cause this problem.
Please help?
Edit: This problem occur in both normal usage with keyboard connected to Pi AND over SSH.
try to switch on the tty using
stty echo
you can try in another shell turning echo off and on again, like
stty -echo // aftewards type something you should not see anything
stty echo // this must be a kind of blind typing
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 11 months ago.
Improve this question
I've written shell scripts using escape codes to move the cursor and change the color. There are however escape codes that return a response.
I'm struggling to figure out how one reads the responses to control codes that query the terminal itself, particularly within a shell script? Codes like <ESC>[6n which is "Query Cursor Position"
It doesn't seem to be standard out or standard error as far as I can tell. I am confused.
In ZSH I do the following
~ » echo "\e[6n"
~ » 3;1R
the response to the query comes through as the next Terminal command, already typed in for me. I don't understand how. I also am unclear why bash doesn't seem to demonstrate this behavior.
What do I read this value from?
The responses come through on the channel from the terminal (or terminal emulator) to the serial port (or other tty device). That's the same channel used for transmitting characters entered at the terminal keyboard; there is no out-of-band signaling.
Since you didn't read the response after sending the query, it was interpreted as a series of keypresses by your shell. The different shells have different responses to the unusual keyboard input.
To read the response properly, you have to take the terminal out of line-based ("icanon" or "cooked") mode and read a byte at a time (from the tty, i.e. possibly stdin, the same place you'd read keyboard input from) until the terminating character is found. And there's no real way to distinguish the response from any real keypresses that happened to occur at the same time.
It's an unclean business, and if you're trying to do it in a shell script you add extra pain.