Using either docker logs foo | less or docker logs foo 2>&1 | less produces readable text, but only with the stderr redirect can one scroll or type /somepattern and obtain matches. Without it, searching gives "Nothing to search (press RETURN)" and a column of ~'s. Given that stderr and stdout aren't the same, why does less show them the same until I start doing something in less? This may be some weird multi-window vim thing that I just don't understand. Thoughts?

I run a Windows command line program (that I can not make accessible) with wine. It apparently writes something to stdout and I'm trying to capture that output, but I can't redirect it. No matter if I redirect stdout or stderr to a file, the program output is still printed on the console and is not written to the file. When I redirect stderr, the wine output goes away, but the program's output is stilled printed on screen. wine program.exe > out # File is empty, program output printed on screen wine program.exe 2> out # Wine output gets redirected to file, program output still printed on screen If I redirect both, the output is neither printed on screen nor written to the file. **Edit:** On Windows, behavior is similar, but when redirecting both, everything is still printed on screen. Here are some examples with the complete output. $ wine program.exe fixme:winediag:start_process Wine Staging 1.9.23 is a testing version containing experimental patches. fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. output by program.exe fixme:msvcrt:__clean_type_info_names_internal (0x100aaa54) stub When I try to redirect the output, this happens: $ wine program.exe > out 2>&1 $ cat out fixme:winediag:start_process Wine Staging 1.9.23 is a testing version containing experimental patches. fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. fixme:msvcrt:__clean_type_info_names_internal (0x100aaa54) stub I.e., the program's console output is completely missing. The program still works fine and writes some files it's supposed to write. As a check, I did the same with pngcrush, and I get what I'd expect. Without redirection: $ wine pngcrush_1_8_10_w32.exe test.png out.png fixme:winediag:start_process Wine Staging 1.9.23 is a testing version containing experimental patches. fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. | pngcrush-1.8.10 | Copyright (C) 1998-2002, 2006-2016 Glenn Randers-Pehrson | Portions Copyright (C) 2005 Greg Roelofs | This is a free, open-source program. Permission is irrevocably | granted to everyone to use this version of pngcrush without | payment of any fee. | Executable name is pngcrush_1_8_10_w32.exe | It was built with bundled libpng-1.6.26 | and is running with bundled libpng-1.6.26 | Copyright (C) 1998-2004, 2006-2016 Glenn Randers-Pehrson, | Copyright (C) 1996, 1997 Andreas Dilger, | Copyright (C) 1995, Guy Eric Schalnat, Group 42 Inc., | and bundled zlib-1.2.8.1-motley, Copyright (C) 1995 (or later), | Jean-loup Gailly and Mark Adler, | and using "clock()". | It was compiled with gcc version 4.8.0 20121015 (experimental). Recompressing IDAT chunks in test.png to out.png Total length of data found in critical chunks = 431830 Critical chunk length, method 1 (ws 15 fm 0 zl 4 zs 0) = 495979 Critical chunk length, method 2 (ws 15 fm 1 zl 4 zs 0) > 495979 Critical chunk length, method 3 (ws 15 fm 5 zl 4 zs 1) = 495354 Critical chunk length, method 6 (ws 15 fm 5 zl 9 zs 0) = 457709 Critical chunk length, method 9 (ws 15 fm 5 zl 2 zs 2) > 457709 Critical chunk length, method 10 (ws 15 fm 5 zl 9 zs 1) = 451813 Best pngcrush method = 10 (ws 15 fm 5 zl 9 zs 1) = 451813 (4.63% critical chunk increase) (4.63% filesize increase) CPU time decode 4.407583, encode 17.094248, other 4294967296.000000, total 17.180143 sec With redirection: $ wine pngcrush_1_8_10_w32.exe test.png out.png > out 2>&1 $ cat out fixme:winediag:start_process Wine Staging 1.9.23 is a testing version containing experimental patches. fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. | pngcrush-1.8.10 | Copyright (C) 1998-2002, 2006-2016 Glenn Randers-Pehrson | Portions Copyright (C) 2005 Greg Roelofs | This is a free, open-source program. Permission is irrevocably | granted to everyone to use this version of pngcrush without | payment of any fee. | Executable name is pngcrush_1_8_10_w32.exe | It was built with bundled libpng-1.6.26 | and is running with bundled libpng-1.6.26 | Copyright (C) 1998-2004, 2006-2016 Glenn Randers-Pehrson, | Copyright (C) 1996, 1997 Andreas Dilger, | Copyright (C) 1995, Guy Eric Schalnat, Group 42 Inc., | and bundled zlib-1.2.8.1-motley, Copyright (C) 1995 (or later), | Jean-loup Gailly and Mark Adler, | and using "clock()". | It was compiled with gcc version 4.8.0 20121015 (experimental). Recompressing IDAT chunks in test.png to out.png Total length of data found in critical chunks = 431830 Critical chunk length, method 1 (ws 15 fm 0 zl 4 zs 0) = 495979 Critical chunk length, method 2 (ws 15 fm 1 zl 4 zs 0) > 495979 Critical chunk length, method 3 (ws 15 fm 5 zl 4 zs 1) = 495354 Critical chunk length, method 6 (ws 15 fm 5 zl 9 zs 0) = 457709 Critical chunk length, method 9 (ws 15 fm 5 zl 2 zs 2) > 457709 Critical chunk length, method 10 (ws 15 fm 5 zl 9 zs 1) = 451813 Best pngcrush method = 10 (ws 15 fm 5 zl 9 zs 1) = 451813 (4.63% critical chunk increase) (4.63% filesize increase) CPU time decode 4.339310, encode 17.137527, other 4.294083, total 17.182100 sec What could be the cause of that not working for the other program? wine stdout stderr io-redirection

Lately, I have been experimenting with the ps command, and sometimes long paths wrap to the next line (or two) and make it hard to read. I want to pipe the ps output into another program to limit the output to x number of characters. Here is what I have so far, but it doesn't work quite right: ps aux | cut -c1-$(stty size | cut -d' ' -f2) $(stty size | cut -d' ' -f2) evaluates to 167, but doesn't seem to be valid input for cut. Is there a way to get this type of syntax to work in bash?

I'm running the following C program

// hello.c

#include 
#include 

int main() {
  while (1) {
    printf("Hello\n");
    fflush(stdout);
    sleep(1);
  }

  return 0;
}

I launched the program using

./hello

and I can see on the terminal its messages. Then I get its pid using. However if I do

tail -f /proc//fd/1

I do not get anything. Ditto if I use

cat /proc//fd/1

I think that I probably misunderstood some concepts about stdout and /proc. It is possible to do what I'm trying to do?

Given a command that changes its behaviour when its output is going to a terminal (e.g. produce coloured output), how can that output be redirected in a pipeline while preserving the changed behaviour? There must be a utility for that, which I am not aware of. Some commands, like grep --color=always, have option flags to force the behaviour, but the question is how to work around programs that rely solely on testing their output file descriptor. If it matters, my shell is bash on Linux.

I'd like to figure out if an external program ran successfully and wrote something to stdout, or if it did not write anything, which happens in case an error occurred. The program unfortunately always returns with exit status 0 and no stderr output. The check should also not modify or hide whatever is being written to stdout by the program. --- If program output is short, it's possible to use command substitution to capture it, store it in an environment variable and print it again:

output="$(external_program)"
printf %s "$output"
if [ -z "$output" ]; then
    # error: external program didn't write anything
fi

Possible dealbreakers: - Depends on size of output, see https://unix.stackexchange.com/questions/357843/setting-a-long-environment-variable-breaks-a-lot-of-commands - Possibly modifies output, notably removes newlines, see https://unix.stackexchange.com/questions/164508/why-do-newline-characters-get-lost-when-using-command-substitution - If external program output is binary data, it's not a good idea to store that in an environment variable (?) --- Another possibility would be to write the output to a temporary file or pipe. This could be wrapped into a function which communicates the result via exit status:

output_exist() (
    temporary_file="$(mktemp)" || exit
    trap 'rm "$temporary_file"' EXIT
    tee "$temporary_file"
    test -s "$temporary_file"
)

if ! external_program | output_exist; then
    # error: external program didn't write anything
fi

Possible dealbreakers: - Temporary file or pipe that has to be taken care of, ensure clean-up etc., convenience vs. portability, e.g. POSIX only has mktemp(3), no mktemp(1) - Very large output may lead to resource/performance issues --- What alternatives are there? Is there a more straightforward solution?

mkfifo foo
printf %s\\n bar | tee foo &
tr -s '[:lower:]' '[:upper:]' 

This is a working POSIX shell script of what I want to do: - printf %s\\n bar is symbolic for an external program producing stdout - tr -s '[:lower:]' '[:upper:]' is symbolic for another command that is supposed to receive the stdout and do something with it - tee duplicates stdout to named pipe foo And the output is as expected:

bar
BAR

Now I'd like to tidy up the code so it becomes external_program | my_function. Something like this:

f() (
  mkfifo foo
  tee foo &
  tr -s '[:lower:]' '[:upper:]' 

But now there is no output at all.