7

I am running iwconfig | grep -v "no wireless extensions" but can't get the -v option to work as expected. I want to exclude lines including "no wireless extensions", i.e., I want to display only the active/working wireless interface or whatever this should be called.

In the beginning I thought perhaps the command outputs to a stream different than the one piped to grep, so I tried cat myFile | grep -v myExclusionPattern. This works as expected, so I concluded -v does what I expect it does. I then tried iwconfig | grep "no wireless extensions" and again the result is the expected - meaning the output of iwconfig is what is piped to grep. So I am left with the question why specifically -v is not working when piping the results of iwconfig to grep.

Here is my output to iwconfig:

enp4s0    no wireless extensions.

docker0   no wireless extensions.

lo        no wireless extensions.

wlp5s0    IEEE 802.11  ESSID:"myEssid"  
          Mode:Managed  Frequency:5.24 GHz  Access Point: 74:83:C2:75:86:2A   
          Bit Rate=6 Mb/s   Tx-Power=30 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=59/70  Signal level=-51 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:747   Missed beacon:0

Summarizing:

  1. grep -v works for me when I pipe to grep the output of a file with cat.
  2. I can't reproduce the same behavior as in (1) when piping the output of iwconfig to grep.

I read the following questions on grep -v, but am not able to find the answer to the above in any of them:

2 Answers 2

13

iwconfig outputs to both standard output and to standard error, depending on whether it found or did not find any wireless extensions for an interface. Piping only affects standard output.

Example removing the output sent to the standard error stream (only shows interfaces that have wireless extensions):

$ /usr/sbin/iwconfig 2>/dev/null
wlp4s0    IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=22 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

Example removing the output sent to the standard output stream (only shows interfaces where iwconfig failed to find wireless extensions):

$ /usr/sbin/iwconfig >/dev/null
lo        no wireless extensions.

enp0s31f6  no wireless extensions.

wwan0     no wireless extensions.

docker0   no wireless extensions.

br-ca679f9ee354  no wireless extensions.

veth232fd86  no wireless extensions.

vboxnet0  no wireless extensions.

5
  • 2
    Got it. What I saw as part of the output of grep was rather the output to the error stream sent by iwconfig. Thanks !
    – Veverke
    Commented Aug 4, 2021 at 10:03
  • 2
    In short - iwconfig does unusual things with its output. iwlist and iwspy also do similar things, so the whole wireless-tools package has a distinctive developer's fingerprint or style.
    – Criggie
    Commented Aug 4, 2021 at 22:00
  • @Criggie: I am not much familiar, you mean tools will not usually output both error and standard outputs to the same stream ? Isn't this actually common ?
    – Veverke
    Commented Aug 5, 2021 at 7:01
  • 2
    @Veverke It just means Criggie and the developer of iwconfig does not quite agree on the use of output streams for various types of output. Errors usually goes to standard error, and non-error output usually goes to standard output. The developer obviously classifies not finding a wireless extension as an "error", whereas Criggie may have opted for sending that information to standard output instead, possibly reserving the error stream for errors such as messages about invalid options and other types of unexpected situations.
    – Kusalananda
    Commented Aug 5, 2021 at 7:14
  • 1
    @Kusalananda correct. From the user's point of view, stderr and stdout look the same on screen. iwconfig | od -a was a good tool to show the difference.
    – Criggie
    Commented Aug 5, 2021 at 11:24
0

I see no one mentioned this alternative, but I would consider using

iwconfig 2>&1 | grep -v "no wireless extensions" a solution as well (perhaps even more elegant ?)

Now both errors and regular output are sent to the same file descriptor (standard output), which is what is piped to grep, which can finally filter the whole data.

5
  • That's a solution too, obviously. I did not mention it in my answer as the grep simply isn't needed to separate the output in the manner that you do here.
    – Kusalananda
    Commented Aug 5, 2021 at 20:22
  • @Kusalananda: don't get why you say grep is not needed. The problem was "how do I filter iwconfig output to exclude "no wireless extensions" lines. One of the most common ways to filter is using grep. Problem was that the input to grep was comming from stdout, and the lines I wanted to filter were not in that data stream, but in another. So uniting all iwconfig outputs to a single one and piping this union to grep (which is still needed) is another (and neat) solution. As far as I understand (I am sure your unix knowledge is definitely far superior than mine, though)
    – Veverke
    Commented Aug 6, 2021 at 9:09
  • grep is not needed to remove the no wireless extensions line because these are sent to the standard error stream. By simply discarding the standard error stream by redirecting it to /dev/null, these lines are removed from what's outputted to the terminal.
    – Kusalananda
    Commented Aug 6, 2021 at 9:33
  • @Kusalananda: Oh I see what you mean, right. Now I understand how "my solution" is not better than yours. In a sense, it adds some redundant steps, I take those lines and redirect them as input to grep, you get rid of them in the first chance, discarding them, assuming data from error fd is not relevant, so grep is left only with relevant data (and yes, in my case nothing to filter, making grep redundant). Thanks for all the help, appreciated !
    – Veverke
    Commented Aug 6, 2021 at 12:30
  • 1
    If you had wanted to filer based on any other piece of information (which could potentially occur on either of the two data streams), then you would have had to combine the steams and run grep over it.
    – Kusalananda
    Commented Aug 6, 2021 at 15:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .