Piping the output of comand columns
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I am using lolcat to get the output of ls in color. To do this i have copied /usr/bin/ls to /usr/bin/lsslss (to avoid an endless loop since alias cannot acccept $* or $@) and I have added the function:
ls(){ lsslss $* | lolcat; }
to .bashrc
The issue is that when i use ls the pipe is piped each file at a time so it shows up as a long list like this:
instead of a table like this:
to change it into a table I can pipe the output into columns command. but when I do it changes back into a long list (probably because of columns only formats it instead of changing it into rows)
I was originally going to do:
ls(){ lsslss $* | columns | lolcat; }
Anyway I was wondering is there a way to pipe the raw output instead of using | to be able to pipe the output of columns into lolcat?
Thanks in advance. Sorry if my question is badly worded or hard to understand. I almost always find the questions already asked so I dont post questions often.
command-line bash pipe stdout
add a comment |
I am using lolcat to get the output of ls in color. To do this i have copied /usr/bin/ls to /usr/bin/lsslss (to avoid an endless loop since alias cannot acccept $* or $@) and I have added the function:
ls(){ lsslss $* | lolcat; }
to .bashrc
The issue is that when i use ls the pipe is piped each file at a time so it shows up as a long list like this:
instead of a table like this:
to change it into a table I can pipe the output into columns command. but when I do it changes back into a long list (probably because of columns only formats it instead of changing it into rows)
I was originally going to do:
ls(){ lsslss $* | columns | lolcat; }
Anyway I was wondering is there a way to pipe the raw output instead of using | to be able to pipe the output of columns into lolcat?
Thanks in advance. Sorry if my question is badly worded or hard to understand. I almost always find the questions already asked so I dont post questions often.
command-line bash pipe stdout
add a comment |
I am using lolcat to get the output of ls in color. To do this i have copied /usr/bin/ls to /usr/bin/lsslss (to avoid an endless loop since alias cannot acccept $* or $@) and I have added the function:
ls(){ lsslss $* | lolcat; }
to .bashrc
The issue is that when i use ls the pipe is piped each file at a time so it shows up as a long list like this:
instead of a table like this:
to change it into a table I can pipe the output into columns command. but when I do it changes back into a long list (probably because of columns only formats it instead of changing it into rows)
I was originally going to do:
ls(){ lsslss $* | columns | lolcat; }
Anyway I was wondering is there a way to pipe the raw output instead of using | to be able to pipe the output of columns into lolcat?
Thanks in advance. Sorry if my question is badly worded or hard to understand. I almost always find the questions already asked so I dont post questions often.
command-line bash pipe stdout
I am using lolcat to get the output of ls in color. To do this i have copied /usr/bin/ls to /usr/bin/lsslss (to avoid an endless loop since alias cannot acccept $* or $@) and I have added the function:
ls(){ lsslss $* | lolcat; }
to .bashrc
The issue is that when i use ls the pipe is piped each file at a time so it shows up as a long list like this:
instead of a table like this:
to change it into a table I can pipe the output into columns command. but when I do it changes back into a long list (probably because of columns only formats it instead of changing it into rows)
I was originally going to do:
ls(){ lsslss $* | columns | lolcat; }
Anyway I was wondering is there a way to pipe the raw output instead of using | to be able to pipe the output of columns into lolcat?
Thanks in advance. Sorry if my question is badly worded or hard to understand. I almost always find the questions already asked so I dont post questions often.
command-line bash pipe stdout
command-line bash pipe stdout
asked May 20 at 11:01
cohill Oniellcohill Oniell
484 bronze badges
484 bronze badges
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Expanding on @dessert's answer, you need a bit more work to make your colored ls
version behave just like the real ls
in (hopefully?) all cases. The problem is that ls
is not meant to be parsed but intended for human eyes only. For that purpose, it strongly adapts how it works depending on the environment, e.g. whether it is connected to a terminal or outputting to a pipe.
First, you don't need a separate /bin/lsslss
executable to avoid recursion. Use the shell built-in command
to call an executable from the disk, ignoring any shell functions or aliases of the same name.
Second, $*
gives you all function arguments as a single string, which is then subject to word-splitting because it is unquoted. This can give surprisingly wrong results if you have arguments with spaces. Always use "$@"
, which exactly preserves all arguments as they were originally given, with no concatenation or further splitting.
And third, depending on where you put the definition, the syntax ls () { ... ;}
to define a function might not work if ls
is already an alias, because alias expansion happens first, causing a syntax error. Use the explicit syntax by writing function
before it.
Then, we can use ls
' -C
flag to manually enable column output:
function ls() { command ls -C "$@" | lolcat ;}
However, if we just do that and pipe the output through lolcat
(or anything else), you will notice that it doesn't use the full width of your terminal any more, but only 80 columns at most. This is because it can not detect the terminal width if its standard out is no longer directly connected to it. Your shell still knows the terminal though, and it populates the COLUMNS
variable with the width it detected. But, as this variable is not exported by default, ls
does not see this value. We can manually pass it on just for this command like:
function ls() { COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ;}
Now we should always get the correct width, but what happens if we really want to pipe ls
through something else? Normally you shouldn't do that, because as I said in the beginning, ls
should never be parsed. Sometimes it might still be useful though (and some scripts might sadly rely on it), so let's try to at least preserve the original behaviour then. Right now, we would always get the columns as output for e.g. ls | cat
. (It's not colored any more there because lolcat
also checks if it outputs to a terminal or pipe and switches colors off in the latter case)
Let's add a check to our function that uses the plain real ls
if it is piped and our fancy rainbow column version only for terminal view. Whether standard out (file descriptor 1) is a terminal/TTY can simply be checked with [[ -t 1 ]]
:
function ls() {
if [[ -t 1 ]] ; then COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ; else command ls "$@" ; fi
}
I think that should suffice to catch all cases where special/different behaviour from ls
is expected, so that your function only adds color when viewed directly in a terminal and otherwise does not alter anything.
Yes that works. Thank you! I was under the impression ls would automatically parse any string given to it but your right.
– cohill Oniell
May 20 at 12:11
That is going beyond the call of duty!
– TRiG
May 20 at 18:21
add a comment |
When its output is piped, ls
disables the column listing. Use the -C
option to explicitly enable it:
ls(){ COLUMNS="$COLUMNS" command ls -C "$@" | lolcat; }
COLUMNS="$COLUMNS"
sets the COLUMNS
variable correctly to the current terminal’s width, without that it defaults to 80 – try resizing your terminal window and compare the outputs. command ls
serves to ignore aliases and functions and call ls
wherever its executable is. Note that I used "$@"
, to quote the Bash Hackers Wiki:
[
"$@"
] reflects all positional parameters as they were set initially
and passed to the script or function. If you want to re-use your
positional parameters to call another program (for example in a
wrapper-script), then this is the choice for you, use double quoted
"$@"
.
Well, let's just say: You almost always want a quoted"$@"
!
1
You might want to export the shell'sCOLUMNS
variable first, so thatls
can still determine how wide the output shall be. Without that, it defaults to 80 characters, I think. And instead of hardcoding/bin/ls
you can alsocommand ls
to force an executable file lookup, ignoring shell functions/aliases.
– Byte Commander♦
May 20 at 11:14
1
Hmm, actually... there's even more stuff needed to not break things.ls
is really a tough one because it is not meant to be parsed and its output strongly depends on the environment. I'll add my own answer.
– Byte Commander♦
May 20 at 11:25
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1144718%2fpiping-the-output-of-comand-columns%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Expanding on @dessert's answer, you need a bit more work to make your colored ls
version behave just like the real ls
in (hopefully?) all cases. The problem is that ls
is not meant to be parsed but intended for human eyes only. For that purpose, it strongly adapts how it works depending on the environment, e.g. whether it is connected to a terminal or outputting to a pipe.
First, you don't need a separate /bin/lsslss
executable to avoid recursion. Use the shell built-in command
to call an executable from the disk, ignoring any shell functions or aliases of the same name.
Second, $*
gives you all function arguments as a single string, which is then subject to word-splitting because it is unquoted. This can give surprisingly wrong results if you have arguments with spaces. Always use "$@"
, which exactly preserves all arguments as they were originally given, with no concatenation or further splitting.
And third, depending on where you put the definition, the syntax ls () { ... ;}
to define a function might not work if ls
is already an alias, because alias expansion happens first, causing a syntax error. Use the explicit syntax by writing function
before it.
Then, we can use ls
' -C
flag to manually enable column output:
function ls() { command ls -C "$@" | lolcat ;}
However, if we just do that and pipe the output through lolcat
(or anything else), you will notice that it doesn't use the full width of your terminal any more, but only 80 columns at most. This is because it can not detect the terminal width if its standard out is no longer directly connected to it. Your shell still knows the terminal though, and it populates the COLUMNS
variable with the width it detected. But, as this variable is not exported by default, ls
does not see this value. We can manually pass it on just for this command like:
function ls() { COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ;}
Now we should always get the correct width, but what happens if we really want to pipe ls
through something else? Normally you shouldn't do that, because as I said in the beginning, ls
should never be parsed. Sometimes it might still be useful though (and some scripts might sadly rely on it), so let's try to at least preserve the original behaviour then. Right now, we would always get the columns as output for e.g. ls | cat
. (It's not colored any more there because lolcat
also checks if it outputs to a terminal or pipe and switches colors off in the latter case)
Let's add a check to our function that uses the plain real ls
if it is piped and our fancy rainbow column version only for terminal view. Whether standard out (file descriptor 1) is a terminal/TTY can simply be checked with [[ -t 1 ]]
:
function ls() {
if [[ -t 1 ]] ; then COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ; else command ls "$@" ; fi
}
I think that should suffice to catch all cases where special/different behaviour from ls
is expected, so that your function only adds color when viewed directly in a terminal and otherwise does not alter anything.
Yes that works. Thank you! I was under the impression ls would automatically parse any string given to it but your right.
– cohill Oniell
May 20 at 12:11
That is going beyond the call of duty!
– TRiG
May 20 at 18:21
add a comment |
Expanding on @dessert's answer, you need a bit more work to make your colored ls
version behave just like the real ls
in (hopefully?) all cases. The problem is that ls
is not meant to be parsed but intended for human eyes only. For that purpose, it strongly adapts how it works depending on the environment, e.g. whether it is connected to a terminal or outputting to a pipe.
First, you don't need a separate /bin/lsslss
executable to avoid recursion. Use the shell built-in command
to call an executable from the disk, ignoring any shell functions or aliases of the same name.
Second, $*
gives you all function arguments as a single string, which is then subject to word-splitting because it is unquoted. This can give surprisingly wrong results if you have arguments with spaces. Always use "$@"
, which exactly preserves all arguments as they were originally given, with no concatenation or further splitting.
And third, depending on where you put the definition, the syntax ls () { ... ;}
to define a function might not work if ls
is already an alias, because alias expansion happens first, causing a syntax error. Use the explicit syntax by writing function
before it.
Then, we can use ls
' -C
flag to manually enable column output:
function ls() { command ls -C "$@" | lolcat ;}
However, if we just do that and pipe the output through lolcat
(or anything else), you will notice that it doesn't use the full width of your terminal any more, but only 80 columns at most. This is because it can not detect the terminal width if its standard out is no longer directly connected to it. Your shell still knows the terminal though, and it populates the COLUMNS
variable with the width it detected. But, as this variable is not exported by default, ls
does not see this value. We can manually pass it on just for this command like:
function ls() { COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ;}
Now we should always get the correct width, but what happens if we really want to pipe ls
through something else? Normally you shouldn't do that, because as I said in the beginning, ls
should never be parsed. Sometimes it might still be useful though (and some scripts might sadly rely on it), so let's try to at least preserve the original behaviour then. Right now, we would always get the columns as output for e.g. ls | cat
. (It's not colored any more there because lolcat
also checks if it outputs to a terminal or pipe and switches colors off in the latter case)
Let's add a check to our function that uses the plain real ls
if it is piped and our fancy rainbow column version only for terminal view. Whether standard out (file descriptor 1) is a terminal/TTY can simply be checked with [[ -t 1 ]]
:
function ls() {
if [[ -t 1 ]] ; then COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ; else command ls "$@" ; fi
}
I think that should suffice to catch all cases where special/different behaviour from ls
is expected, so that your function only adds color when viewed directly in a terminal and otherwise does not alter anything.
Yes that works. Thank you! I was under the impression ls would automatically parse any string given to it but your right.
– cohill Oniell
May 20 at 12:11
That is going beyond the call of duty!
– TRiG
May 20 at 18:21
add a comment |
Expanding on @dessert's answer, you need a bit more work to make your colored ls
version behave just like the real ls
in (hopefully?) all cases. The problem is that ls
is not meant to be parsed but intended for human eyes only. For that purpose, it strongly adapts how it works depending on the environment, e.g. whether it is connected to a terminal or outputting to a pipe.
First, you don't need a separate /bin/lsslss
executable to avoid recursion. Use the shell built-in command
to call an executable from the disk, ignoring any shell functions or aliases of the same name.
Second, $*
gives you all function arguments as a single string, which is then subject to word-splitting because it is unquoted. This can give surprisingly wrong results if you have arguments with spaces. Always use "$@"
, which exactly preserves all arguments as they were originally given, with no concatenation or further splitting.
And third, depending on where you put the definition, the syntax ls () { ... ;}
to define a function might not work if ls
is already an alias, because alias expansion happens first, causing a syntax error. Use the explicit syntax by writing function
before it.
Then, we can use ls
' -C
flag to manually enable column output:
function ls() { command ls -C "$@" | lolcat ;}
However, if we just do that and pipe the output through lolcat
(or anything else), you will notice that it doesn't use the full width of your terminal any more, but only 80 columns at most. This is because it can not detect the terminal width if its standard out is no longer directly connected to it. Your shell still knows the terminal though, and it populates the COLUMNS
variable with the width it detected. But, as this variable is not exported by default, ls
does not see this value. We can manually pass it on just for this command like:
function ls() { COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ;}
Now we should always get the correct width, but what happens if we really want to pipe ls
through something else? Normally you shouldn't do that, because as I said in the beginning, ls
should never be parsed. Sometimes it might still be useful though (and some scripts might sadly rely on it), so let's try to at least preserve the original behaviour then. Right now, we would always get the columns as output for e.g. ls | cat
. (It's not colored any more there because lolcat
also checks if it outputs to a terminal or pipe and switches colors off in the latter case)
Let's add a check to our function that uses the plain real ls
if it is piped and our fancy rainbow column version only for terminal view. Whether standard out (file descriptor 1) is a terminal/TTY can simply be checked with [[ -t 1 ]]
:
function ls() {
if [[ -t 1 ]] ; then COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ; else command ls "$@" ; fi
}
I think that should suffice to catch all cases where special/different behaviour from ls
is expected, so that your function only adds color when viewed directly in a terminal and otherwise does not alter anything.
Expanding on @dessert's answer, you need a bit more work to make your colored ls
version behave just like the real ls
in (hopefully?) all cases. The problem is that ls
is not meant to be parsed but intended for human eyes only. For that purpose, it strongly adapts how it works depending on the environment, e.g. whether it is connected to a terminal or outputting to a pipe.
First, you don't need a separate /bin/lsslss
executable to avoid recursion. Use the shell built-in command
to call an executable from the disk, ignoring any shell functions or aliases of the same name.
Second, $*
gives you all function arguments as a single string, which is then subject to word-splitting because it is unquoted. This can give surprisingly wrong results if you have arguments with spaces. Always use "$@"
, which exactly preserves all arguments as they were originally given, with no concatenation or further splitting.
And third, depending on where you put the definition, the syntax ls () { ... ;}
to define a function might not work if ls
is already an alias, because alias expansion happens first, causing a syntax error. Use the explicit syntax by writing function
before it.
Then, we can use ls
' -C
flag to manually enable column output:
function ls() { command ls -C "$@" | lolcat ;}
However, if we just do that and pipe the output through lolcat
(or anything else), you will notice that it doesn't use the full width of your terminal any more, but only 80 columns at most. This is because it can not detect the terminal width if its standard out is no longer directly connected to it. Your shell still knows the terminal though, and it populates the COLUMNS
variable with the width it detected. But, as this variable is not exported by default, ls
does not see this value. We can manually pass it on just for this command like:
function ls() { COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ;}
Now we should always get the correct width, but what happens if we really want to pipe ls
through something else? Normally you shouldn't do that, because as I said in the beginning, ls
should never be parsed. Sometimes it might still be useful though (and some scripts might sadly rely on it), so let's try to at least preserve the original behaviour then. Right now, we would always get the columns as output for e.g. ls | cat
. (It's not colored any more there because lolcat
also checks if it outputs to a terminal or pipe and switches colors off in the latter case)
Let's add a check to our function that uses the plain real ls
if it is piped and our fancy rainbow column version only for terminal view. Whether standard out (file descriptor 1) is a terminal/TTY can simply be checked with [[ -t 1 ]]
:
function ls() {
if [[ -t 1 ]] ; then COLUMNS="$COLUMNS" command ls -C "$@" | lolcat ; else command ls "$@" ; fi
}
I think that should suffice to catch all cases where special/different behaviour from ls
is expected, so that your function only adds color when viewed directly in a terminal and otherwise does not alter anything.
answered May 20 at 11:54
Byte Commander♦Byte Commander
70.9k27 gold badges193 silver badges326 bronze badges
70.9k27 gold badges193 silver badges326 bronze badges
Yes that works. Thank you! I was under the impression ls would automatically parse any string given to it but your right.
– cohill Oniell
May 20 at 12:11
That is going beyond the call of duty!
– TRiG
May 20 at 18:21
add a comment |
Yes that works. Thank you! I was under the impression ls would automatically parse any string given to it but your right.
– cohill Oniell
May 20 at 12:11
That is going beyond the call of duty!
– TRiG
May 20 at 18:21
Yes that works. Thank you! I was under the impression ls would automatically parse any string given to it but your right.
– cohill Oniell
May 20 at 12:11
Yes that works. Thank you! I was under the impression ls would automatically parse any string given to it but your right.
– cohill Oniell
May 20 at 12:11
That is going beyond the call of duty!
– TRiG
May 20 at 18:21
That is going beyond the call of duty!
– TRiG
May 20 at 18:21
add a comment |
When its output is piped, ls
disables the column listing. Use the -C
option to explicitly enable it:
ls(){ COLUMNS="$COLUMNS" command ls -C "$@" | lolcat; }
COLUMNS="$COLUMNS"
sets the COLUMNS
variable correctly to the current terminal’s width, without that it defaults to 80 – try resizing your terminal window and compare the outputs. command ls
serves to ignore aliases and functions and call ls
wherever its executable is. Note that I used "$@"
, to quote the Bash Hackers Wiki:
[
"$@"
] reflects all positional parameters as they were set initially
and passed to the script or function. If you want to re-use your
positional parameters to call another program (for example in a
wrapper-script), then this is the choice for you, use double quoted
"$@"
.
Well, let's just say: You almost always want a quoted"$@"
!
1
You might want to export the shell'sCOLUMNS
variable first, so thatls
can still determine how wide the output shall be. Without that, it defaults to 80 characters, I think. And instead of hardcoding/bin/ls
you can alsocommand ls
to force an executable file lookup, ignoring shell functions/aliases.
– Byte Commander♦
May 20 at 11:14
1
Hmm, actually... there's even more stuff needed to not break things.ls
is really a tough one because it is not meant to be parsed and its output strongly depends on the environment. I'll add my own answer.
– Byte Commander♦
May 20 at 11:25
add a comment |
When its output is piped, ls
disables the column listing. Use the -C
option to explicitly enable it:
ls(){ COLUMNS="$COLUMNS" command ls -C "$@" | lolcat; }
COLUMNS="$COLUMNS"
sets the COLUMNS
variable correctly to the current terminal’s width, without that it defaults to 80 – try resizing your terminal window and compare the outputs. command ls
serves to ignore aliases and functions and call ls
wherever its executable is. Note that I used "$@"
, to quote the Bash Hackers Wiki:
[
"$@"
] reflects all positional parameters as they were set initially
and passed to the script or function. If you want to re-use your
positional parameters to call another program (for example in a
wrapper-script), then this is the choice for you, use double quoted
"$@"
.
Well, let's just say: You almost always want a quoted"$@"
!
1
You might want to export the shell'sCOLUMNS
variable first, so thatls
can still determine how wide the output shall be. Without that, it defaults to 80 characters, I think. And instead of hardcoding/bin/ls
you can alsocommand ls
to force an executable file lookup, ignoring shell functions/aliases.
– Byte Commander♦
May 20 at 11:14
1
Hmm, actually... there's even more stuff needed to not break things.ls
is really a tough one because it is not meant to be parsed and its output strongly depends on the environment. I'll add my own answer.
– Byte Commander♦
May 20 at 11:25
add a comment |
When its output is piped, ls
disables the column listing. Use the -C
option to explicitly enable it:
ls(){ COLUMNS="$COLUMNS" command ls -C "$@" | lolcat; }
COLUMNS="$COLUMNS"
sets the COLUMNS
variable correctly to the current terminal’s width, without that it defaults to 80 – try resizing your terminal window and compare the outputs. command ls
serves to ignore aliases and functions and call ls
wherever its executable is. Note that I used "$@"
, to quote the Bash Hackers Wiki:
[
"$@"
] reflects all positional parameters as they were set initially
and passed to the script or function. If you want to re-use your
positional parameters to call another program (for example in a
wrapper-script), then this is the choice for you, use double quoted
"$@"
.
Well, let's just say: You almost always want a quoted"$@"
!
When its output is piped, ls
disables the column listing. Use the -C
option to explicitly enable it:
ls(){ COLUMNS="$COLUMNS" command ls -C "$@" | lolcat; }
COLUMNS="$COLUMNS"
sets the COLUMNS
variable correctly to the current terminal’s width, without that it defaults to 80 – try resizing your terminal window and compare the outputs. command ls
serves to ignore aliases and functions and call ls
wherever its executable is. Note that I used "$@"
, to quote the Bash Hackers Wiki:
[
"$@"
] reflects all positional parameters as they were set initially
and passed to the script or function. If you want to re-use your
positional parameters to call another program (for example in a
wrapper-script), then this is the choice for you, use double quoted
"$@"
.
Well, let's just say: You almost always want a quoted"$@"
!
edited May 20 at 11:26
answered May 20 at 11:08
dessertdessert
28.2k6 gold badges84 silver badges117 bronze badges
28.2k6 gold badges84 silver badges117 bronze badges
1
You might want to export the shell'sCOLUMNS
variable first, so thatls
can still determine how wide the output shall be. Without that, it defaults to 80 characters, I think. And instead of hardcoding/bin/ls
you can alsocommand ls
to force an executable file lookup, ignoring shell functions/aliases.
– Byte Commander♦
May 20 at 11:14
1
Hmm, actually... there's even more stuff needed to not break things.ls
is really a tough one because it is not meant to be parsed and its output strongly depends on the environment. I'll add my own answer.
– Byte Commander♦
May 20 at 11:25
add a comment |
1
You might want to export the shell'sCOLUMNS
variable first, so thatls
can still determine how wide the output shall be. Without that, it defaults to 80 characters, I think. And instead of hardcoding/bin/ls
you can alsocommand ls
to force an executable file lookup, ignoring shell functions/aliases.
– Byte Commander♦
May 20 at 11:14
1
Hmm, actually... there's even more stuff needed to not break things.ls
is really a tough one because it is not meant to be parsed and its output strongly depends on the environment. I'll add my own answer.
– Byte Commander♦
May 20 at 11:25
1
1
You might want to export the shell's
COLUMNS
variable first, so that ls
can still determine how wide the output shall be. Without that, it defaults to 80 characters, I think. And instead of hardcoding /bin/ls
you can also command ls
to force an executable file lookup, ignoring shell functions/aliases.– Byte Commander♦
May 20 at 11:14
You might want to export the shell's
COLUMNS
variable first, so that ls
can still determine how wide the output shall be. Without that, it defaults to 80 characters, I think. And instead of hardcoding /bin/ls
you can also command ls
to force an executable file lookup, ignoring shell functions/aliases.– Byte Commander♦
May 20 at 11:14
1
1
Hmm, actually... there's even more stuff needed to not break things.
ls
is really a tough one because it is not meant to be parsed and its output strongly depends on the environment. I'll add my own answer.– Byte Commander♦
May 20 at 11:25
Hmm, actually... there's even more stuff needed to not break things.
ls
is really a tough one because it is not meant to be parsed and its output strongly depends on the environment. I'll add my own answer.– Byte Commander♦
May 20 at 11:25
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1144718%2fpiping-the-output-of-comand-columns%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown