How do I identify the “sudo … ” command output format?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I am enclosing bash -x output which shows that the command "sudo iwlist wlan0 scan" was executed and returned expected text to terminal .
The issue is - this text was not passed to whiptail msgbox option.



This fails with other "sudo ... " commands, and only with "sudo .. commands.
My guess is there are non printing characters in the output text causing this issue.



sudo iwlist wlan0 scan
wlan0 Interface doesn't support scanning : Network is down

whiptail --title 'Command sudo iwlist wlan0 scan output 1400' - -separate-output --scrolltext --msgbox '' 17 80 10









share|improve this question























  • I like to totally rebuild my question - is that OK?
    – Jan Hus
    Sep 12 at 15:42














up vote
1
down vote

favorite












I am enclosing bash -x output which shows that the command "sudo iwlist wlan0 scan" was executed and returned expected text to terminal .
The issue is - this text was not passed to whiptail msgbox option.



This fails with other "sudo ... " commands, and only with "sudo .. commands.
My guess is there are non printing characters in the output text causing this issue.



sudo iwlist wlan0 scan
wlan0 Interface doesn't support scanning : Network is down

whiptail --title 'Command sudo iwlist wlan0 scan output 1400' - -separate-output --scrolltext --msgbox '' 17 80 10









share|improve this question























  • I like to totally rebuild my question - is that OK?
    – Jan Hus
    Sep 12 at 15:42












up vote
1
down vote

favorite









up vote
1
down vote

favorite











I am enclosing bash -x output which shows that the command "sudo iwlist wlan0 scan" was executed and returned expected text to terminal .
The issue is - this text was not passed to whiptail msgbox option.



This fails with other "sudo ... " commands, and only with "sudo .. commands.
My guess is there are non printing characters in the output text causing this issue.



sudo iwlist wlan0 scan
wlan0 Interface doesn't support scanning : Network is down

whiptail --title 'Command sudo iwlist wlan0 scan output 1400' - -separate-output --scrolltext --msgbox '' 17 80 10









share|improve this question















I am enclosing bash -x output which shows that the command "sudo iwlist wlan0 scan" was executed and returned expected text to terminal .
The issue is - this text was not passed to whiptail msgbox option.



This fails with other "sudo ... " commands, and only with "sudo .. commands.
My guess is there are non printing characters in the output text causing this issue.



sudo iwlist wlan0 scan
wlan0 Interface doesn't support scanning : Network is down

whiptail --title 'Command sudo iwlist wlan0 scan output 1400' - -separate-output --scrolltext --msgbox '' 17 80 10






io-redirection






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 25 at 21:19

























asked Sep 10 at 22:10









Jan Hus

1466




1466











  • I like to totally rebuild my question - is that OK?
    – Jan Hus
    Sep 12 at 15:42
















  • I like to totally rebuild my question - is that OK?
    – Jan Hus
    Sep 12 at 15:42















I like to totally rebuild my question - is that OK?
– Jan Hus
Sep 12 at 15:42




I like to totally rebuild my question - is that OK?
– Jan Hus
Sep 12 at 15:42










1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted












Whenever you are not sure, try redirecting the stdout then stderr to /dev/null.

For example, with lsusb -h > /dev/null you can still see the output, whereas with lsusb -h 2> /dev/null there's not output - therefore, the output of the help goes to stderr.

If you want to redirect stderr to stdout:
lsusb -h 2>&1

It's not obvious (at first) but what this command does is redirect stderr (file descriptor #2) to stdout (file descriptor #1).






share|improve this answer




















  • lsusb -h > /dev/null you can still see the output yes I do in terminal and it locks it up I need to see it on screen "stdout"
    – Jan Hus
    Sep 11 at 16:44











  • Actually I see all on terminal, the variable is passed to whiptail which I need to redirect.
    – Jan Hus
    Sep 11 at 16:47










  • Well, without any additional information from your part, it's going to be hard to help you! ;) The example below works, but I don't know how well it would fit into your script: whiptail --msgbox "$(lsusb 2>&1)" 20 80
    – pi0tr
    Sep 13 at 13:05











  • What other info do you need?
    – Jan Hus
    Sep 13 at 14:16










  • Well, I have no idea what your script does, or how it works. This makes it hard to be relevant. From what I understand, you want some variable to hold both the stdout and stderr output of the lsudb command. For example: var=$(lsusb -h 2>&1) The variable var will hold both stdout and stderr; you can then use it with whiptail: whiptail --msgbox "$var" 20 80
    – pi0tr
    Sep 13 at 16:54










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f468122%2fhow-do-i-identify-the-sudo-command-output-format%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote



accepted












Whenever you are not sure, try redirecting the stdout then stderr to /dev/null.

For example, with lsusb -h > /dev/null you can still see the output, whereas with lsusb -h 2> /dev/null there's not output - therefore, the output of the help goes to stderr.

If you want to redirect stderr to stdout:
lsusb -h 2>&1

It's not obvious (at first) but what this command does is redirect stderr (file descriptor #2) to stdout (file descriptor #1).






share|improve this answer




















  • lsusb -h > /dev/null you can still see the output yes I do in terminal and it locks it up I need to see it on screen "stdout"
    – Jan Hus
    Sep 11 at 16:44











  • Actually I see all on terminal, the variable is passed to whiptail which I need to redirect.
    – Jan Hus
    Sep 11 at 16:47










  • Well, without any additional information from your part, it's going to be hard to help you! ;) The example below works, but I don't know how well it would fit into your script: whiptail --msgbox "$(lsusb 2>&1)" 20 80
    – pi0tr
    Sep 13 at 13:05











  • What other info do you need?
    – Jan Hus
    Sep 13 at 14:16










  • Well, I have no idea what your script does, or how it works. This makes it hard to be relevant. From what I understand, you want some variable to hold both the stdout and stderr output of the lsudb command. For example: var=$(lsusb -h 2>&1) The variable var will hold both stdout and stderr; you can then use it with whiptail: whiptail --msgbox "$var" 20 80
    – pi0tr
    Sep 13 at 16:54














up vote
0
down vote



accepted












Whenever you are not sure, try redirecting the stdout then stderr to /dev/null.

For example, with lsusb -h > /dev/null you can still see the output, whereas with lsusb -h 2> /dev/null there's not output - therefore, the output of the help goes to stderr.

If you want to redirect stderr to stdout:
lsusb -h 2>&1

It's not obvious (at first) but what this command does is redirect stderr (file descriptor #2) to stdout (file descriptor #1).






share|improve this answer




















  • lsusb -h > /dev/null you can still see the output yes I do in terminal and it locks it up I need to see it on screen "stdout"
    – Jan Hus
    Sep 11 at 16:44











  • Actually I see all on terminal, the variable is passed to whiptail which I need to redirect.
    – Jan Hus
    Sep 11 at 16:47










  • Well, without any additional information from your part, it's going to be hard to help you! ;) The example below works, but I don't know how well it would fit into your script: whiptail --msgbox "$(lsusb 2>&1)" 20 80
    – pi0tr
    Sep 13 at 13:05











  • What other info do you need?
    – Jan Hus
    Sep 13 at 14:16










  • Well, I have no idea what your script does, or how it works. This makes it hard to be relevant. From what I understand, you want some variable to hold both the stdout and stderr output of the lsudb command. For example: var=$(lsusb -h 2>&1) The variable var will hold both stdout and stderr; you can then use it with whiptail: whiptail --msgbox "$var" 20 80
    – pi0tr
    Sep 13 at 16:54












up vote
0
down vote



accepted







up vote
0
down vote



accepted








Whenever you are not sure, try redirecting the stdout then stderr to /dev/null.

For example, with lsusb -h > /dev/null you can still see the output, whereas with lsusb -h 2> /dev/null there's not output - therefore, the output of the help goes to stderr.

If you want to redirect stderr to stdout:
lsusb -h 2>&1

It's not obvious (at first) but what this command does is redirect stderr (file descriptor #2) to stdout (file descriptor #1).






share|improve this answer














Whenever you are not sure, try redirecting the stdout then stderr to /dev/null.

For example, with lsusb -h > /dev/null you can still see the output, whereas with lsusb -h 2> /dev/null there's not output - therefore, the output of the help goes to stderr.

If you want to redirect stderr to stdout:
lsusb -h 2>&1

It's not obvious (at first) but what this command does is redirect stderr (file descriptor #2) to stdout (file descriptor #1).







share|improve this answer












share|improve this answer



share|improve this answer










answered Sep 10 at 22:23









pi0tr

1652




1652











  • lsusb -h > /dev/null you can still see the output yes I do in terminal and it locks it up I need to see it on screen "stdout"
    – Jan Hus
    Sep 11 at 16:44











  • Actually I see all on terminal, the variable is passed to whiptail which I need to redirect.
    – Jan Hus
    Sep 11 at 16:47










  • Well, without any additional information from your part, it's going to be hard to help you! ;) The example below works, but I don't know how well it would fit into your script: whiptail --msgbox "$(lsusb 2>&1)" 20 80
    – pi0tr
    Sep 13 at 13:05











  • What other info do you need?
    – Jan Hus
    Sep 13 at 14:16










  • Well, I have no idea what your script does, or how it works. This makes it hard to be relevant. From what I understand, you want some variable to hold both the stdout and stderr output of the lsudb command. For example: var=$(lsusb -h 2>&1) The variable var will hold both stdout and stderr; you can then use it with whiptail: whiptail --msgbox "$var" 20 80
    – pi0tr
    Sep 13 at 16:54
















  • lsusb -h > /dev/null you can still see the output yes I do in terminal and it locks it up I need to see it on screen "stdout"
    – Jan Hus
    Sep 11 at 16:44











  • Actually I see all on terminal, the variable is passed to whiptail which I need to redirect.
    – Jan Hus
    Sep 11 at 16:47










  • Well, without any additional information from your part, it's going to be hard to help you! ;) The example below works, but I don't know how well it would fit into your script: whiptail --msgbox "$(lsusb 2>&1)" 20 80
    – pi0tr
    Sep 13 at 13:05











  • What other info do you need?
    – Jan Hus
    Sep 13 at 14:16










  • Well, I have no idea what your script does, or how it works. This makes it hard to be relevant. From what I understand, you want some variable to hold both the stdout and stderr output of the lsudb command. For example: var=$(lsusb -h 2>&1) The variable var will hold both stdout and stderr; you can then use it with whiptail: whiptail --msgbox "$var" 20 80
    – pi0tr
    Sep 13 at 16:54















lsusb -h > /dev/null you can still see the output yes I do in terminal and it locks it up I need to see it on screen "stdout"
– Jan Hus
Sep 11 at 16:44





lsusb -h > /dev/null you can still see the output yes I do in terminal and it locks it up I need to see it on screen "stdout"
– Jan Hus
Sep 11 at 16:44













Actually I see all on terminal, the variable is passed to whiptail which I need to redirect.
– Jan Hus
Sep 11 at 16:47




Actually I see all on terminal, the variable is passed to whiptail which I need to redirect.
– Jan Hus
Sep 11 at 16:47












Well, without any additional information from your part, it's going to be hard to help you! ;) The example below works, but I don't know how well it would fit into your script: whiptail --msgbox "$(lsusb 2>&1)" 20 80
– pi0tr
Sep 13 at 13:05





Well, without any additional information from your part, it's going to be hard to help you! ;) The example below works, but I don't know how well it would fit into your script: whiptail --msgbox "$(lsusb 2>&1)" 20 80
– pi0tr
Sep 13 at 13:05













What other info do you need?
– Jan Hus
Sep 13 at 14:16




What other info do you need?
– Jan Hus
Sep 13 at 14:16












Well, I have no idea what your script does, or how it works. This makes it hard to be relevant. From what I understand, you want some variable to hold both the stdout and stderr output of the lsudb command. For example: var=$(lsusb -h 2>&1) The variable var will hold both stdout and stderr; you can then use it with whiptail: whiptail --msgbox "$var" 20 80
– pi0tr
Sep 13 at 16:54




Well, I have no idea what your script does, or how it works. This makes it hard to be relevant. From what I understand, you want some variable to hold both the stdout and stderr output of the lsudb command. For example: var=$(lsusb -h 2>&1) The variable var will hold both stdout and stderr; you can then use it with whiptail: whiptail --msgbox "$var" 20 80
– pi0tr
Sep 13 at 16:54

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f468122%2fhow-do-i-identify-the-sudo-command-output-format%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?