Computing desk
< June 25	<< May \| June \| Jul >>	June 27 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

June 26

Pipe output to two commands

In Unix I'd like to cat a file and output both the the word count (wc -w) and contents... can it be done with one command? I thought tee would work but I don't actually want to write it to a file, just show the count and contents in standard output. Thx. 98.110.131.11 (talk) 13:34, 26 June 2020 (UTC)[reply]

I note the reference to UNIX, so you need to check this against your particular implementation of tee. The GNU utilities which are sometimes found on UNIX and always on Linux may differ slightly, so this may or may not answer your question. GNU coreutils v5.3.0 - c8.23 permitted a FILE parameter of "-" which directed the text to standard output. For these versions cat X | tee - | wc -w should work, but I've not tested it. More modern implementations of BASH (importantly, invoked as /bin/bash and not /bin/sh) allows redirection to a process using the >() syntax. For instance cat X | tee >(wc -w) which on my machine typed out the file X and then added "31" at the end. Martin of Sheffield (talk) 14:31, 26 June 2020 (UTC)[reply]

The second idea worked great in zsh which is what I was using (on Mac). In bash it worked but printed an extra line waiting for user input... pressing enter would allow it to terminate. Thank you for the help. 98.110.131.11 (talk) 15:39, 26 June 2020 (UTC)[reply]

GNU (coreutils) tee doesn't support the - option (because it's already sending to stdout, and this would entail it having two different stdouts). A hack is to do tee /dev/tty | wc -- Finlay McWalter··–·Talk 15:57, 26 June 2020 (UTC)[reply]

@Finlay McWalter: – Hi Finlay, the documentation says:

In previous versions of GNU coreutils (v5.3.0 - v8.23), a FILE of ‘-’ caused ‘tee’ to send another copy of input to standard output. However, as the interleaved output was not very useful, ‘tee’ now conforms to POSIX which explicitly mandates it to treat ‘-’ as a file with such name.
— info '(coreutils) tee invocation'

There's no inherent reason why two streams can't both write to stdout, consider constructs such as 2>&1 for example. The problem is that the streams mix unpredictably Chapter 3 of the Bash Reference Manual gives the detail. Regards, Martin of Sheffield (talk) 16:27, 26 June 2020 (UTC)[reply]

What you can't do is have one program write to two different places and have both of them be stdout at the same time. The suggestion of teeing to /dev/tty works, though. By the way, you don't need to use cat in the example at all, if the input is a single file; just redirect tee's stdin. Thus: tee /dev/tty <X | wc -w

Clearly wc can't produce its output until tee finishes running, but that's not a guarantee that the output will reach your screen only after tee's output to /dev/tty finishes reaching your screen. --76.71.5.208 (talk) 22:26, 26 June 2020 (UTC)[reply]

Your second point is valid, that's why GNU coreutils was changed, see the quote above. Your first point though is inaccurate. Consider the following commands:

 $ grep SLAVE *
 grep: bin: Is a directory
 ifcfg.txt:    SLAVE=yes
 $ grep SLAVE * 2>/dev/null
 ifcfg.txt:    SLAVE=yes
 $ grep SLAVE * 1>/dev/null
 grep: bin: Is a directory
 $ grep SLAVE * 1>/dev/null 2>&1
 $ grep SLAVE * 2>&1
 grep: bin: Is a directory
 ifcfg.txt:    SLAVE=yes
 $

We start with grep producing two l ines, one to stdout and one to stderr. Next the stderr is send to the bitbucket. The third example show stdout going to the bit bucket and we see the stderr. The fourth example shows stdout being sent to /dev/null and stderr being sent to the same place. Note that as far as grep is concerned these are separate units, BASH is uniting them. The final example shows stderr being sent to the same unit as stdout, but in this case it is /dev/tty. Grep is indeed writing to two separate places, and yet the data streams can be sent to the same place (wherever stdout points). I might point out that the cited text is taken from the official documentation. Martin of Sheffield (talk) 22:44, 26 June 2020 (UTC)[reply]

I didn't say a second output can't go to the same place stdout points, I said it couldn't also be stdout. --76.71.5.208 (talk) 06:45, 27 June 2020 (UTC)[reply]

wc -w foo; cat foo; does the trick. Is there a particular reason it has to be one command? If it's for convenience in interactive shells, put a shell function in your shell startup file(s) (a.k.a. rc files or "dotfiles"). For zsh, looks like this is simple: most likely ~/.zshrc. bash is unfortunately more complicated, especially when a GUI environment is introduced. You'll want to read this, but it focuses on Linux with X; I don't know how OS X configures its environment. Anyway, you want something like cprint(){ wc -w "$@"; cat "$@"; }. That will handle any number of filenames. If you want file 1's word count, followed by contents, followed by file 2's word count…you can refactor it to loop through the arguments instead. --47.146.63.87 (talk) 19:36, 28 June 2020 (UTC)[reply]

Windows 10 PC runs slow. Could it be due to recent ver. 10.0.18362 Build 18362?

Normally I wouldn't be asking for help with a slow computer, but I'm wondering if the problem could be due to the most recent Win 10 update, which was installed on June 17 (version 10.0.18362 Build 18362). This is about how long I have been experiencing the problem. I called the cable provider and we ruled out the modem and router. Also another computer on the network works fine (167 mb/s download) as does my phone (about the same). On this computer I get from 6 to 26 mb/s. Can anybody help? --Halcatalyst (talk) 20:35, 26 June 2020 (UTC)[reply]

Halcatalyst, so the problem is not actually a slow computer, but slow network bandwidth? Could you clarify if you mean megabits per second or megabytes per second? What server are you downloading from and how far is it across the Internet? Have you done a traceroute? Pings? What other network diagnostics have you tried? Is it one large file or several smaller ones? Elizium23 (talk) 20:49, 26 June 2020 (UTC)[reply]

Megabits per second. I think it's the computer rather than the network speed, since both the phone and the other computer are in the expected speed range (nominally 200 megs and they get in the 160s). My Internet connection is Mediacom cable. Don't know what a traceroute is or how I would do network diagnostics. The problem seems to affect all my downloads, but especially image-heavy sites like my personal web page, which has a lot of pictures on it. --Halcatalyst (talk) 21:48, 26 June 2020 (UTC)[reply]

Halcatalyst, try visiting speedtest.net and see if it can determine a baseline speed; compare it to the other devices. Elizium23 (talk) 21:57, 26 June 2020 (UTC)[reply]

I went back and cleared my browsing history and a couple of other things, and now I'm getting different results with speedtest on my laptop, from about 100 to 150-160. Same on the phone and the other computer. I don't understand the variety, but at least they're in an acceptable range now. Thank you for our help! --Halcatalyst (talk) 01:47, 27 June 2020 (UTC)[reply]

Was the computer connected via Wi-Fi? If so it's probably that. Wi-Fi, being a radio transmission in an "uncontrolled" frequency spectrum, is prone to all kinds of things that can randomly degrade performance. If you're using a wireless connection and you start having issues, the first troubleshooting step is to try a wired connection if possible and see if that makes a difference. --47.146.63.87 (talk) 17:36, 1 July 2020 (UTC)[reply]