terminal command ls

-1

An interesting observation.

Whether you us l, ls, ll, ls -a, or ls -l, the command becomes recursive and if you happen to be trying to resolve link errors, you end up going through pages of unnecessary crap in search of your actual needs. This is especially true if the link you search is (as in my case) a folder.

I was looking to repair a link to python3.6 which normally comes through python3 (when installed normally). ll pyth* used to list simply all the links that get setup and I could peruse the list and repair as needed. However, right now, it lists

python3:

. .. dist-packages

python3.6

.

..

the entire list of python3.6

etc...

and in neither case does it even allude to the links.

Fresh install of 18.10, any thoughts??

asked Mar 11 at 17:47

Mitch Oldroyd

3

Perhaps you're looking for the -d (--directory) option? list directories themselves, not their contents

– steeldriver
Mar 11 at 17:51

"whether you us l, ls, ll, ls -a, or ls -l, the command becomes recursive" since when? cuz that only happens when you use -r as an option

– Rinzwind
Mar 11 at 17:59

add a comment |

-1

An interesting observation.

python3:

. .. dist-packages

python3.6

.

..

the entire list of python3.6

etc...

and in neither case does it even allude to the links.

Fresh install of 18.10, any thoughts??

asked Mar 11 at 17:47

Mitch Oldroyd

3

Perhaps you're looking for the -d (--directory) option? list directories themselves, not their contents

– steeldriver
Mar 11 at 17:51

"whether you us l, ls, ll, ls -a, or ls -l, the command becomes recursive" since when? cuz that only happens when you use -r as an option

– Rinzwind
Mar 11 at 17:59

add a comment |

-1

An interesting observation.

python3:

. .. dist-packages

python3.6

.

..

the entire list of python3.6

etc...

and in neither case does it even allude to the links.

Fresh install of 18.10, any thoughts??

asked Mar 11 at 17:47

Mitch Oldroyd

An interesting observation.

python3:

. .. dist-packages

python3.6

.

..

the entire list of python3.6

etc...

and in neither case does it even allude to the links.

Fresh install of 18.10, any thoughts??

command-line directory

asked Mar 11 at 17:47

Mitch Oldroyd

asked Mar 11 at 17:47

Mitch Oldroyd

asked Mar 11 at 17:47

Mitch Oldroyd

asked Mar 11 at 17:47

Mitch Oldroyd

asked Mar 11 at 17:47

Mitch Oldroyd

3

Perhaps you're looking for the -d (--directory) option? list directories themselves, not their contents

– steeldriver
Mar 11 at 17:51

"whether you us l, ls, ll, ls -a, or ls -l, the command becomes recursive" since when? cuz that only happens when you use -r as an option

– Rinzwind
Mar 11 at 17:59

add a comment |

3

Perhaps you're looking for the -d (--directory) option? list directories themselves, not their contents

– steeldriver
Mar 11 at 17:51

"whether you us l, ls, ll, ls -a, or ls -l, the command becomes recursive" since when? cuz that only happens when you use -r as an option

– Rinzwind
Mar 11 at 17:59

Perhaps you're looking for the -d (--directory) option? list directories themselves, not their contents

– steeldriver
Mar 11 at 17:51

"whether you us l, ls, ll, ls -a, or ls -l, the command becomes recursive" since when? cuz that only happens when you use -r as an option

– Rinzwind
Mar 11 at 17:59

add a comment |

1 Answer
1

active

oldest

votes

The output you're getting is because you're using shell pattern matching (globbing) of pyth* and running the ls command on each element output by the glob.

The shell returns the python3 and python3.6 directories first along with any other matches. They are used as arguments to ls so your command ends up as

ls python3 python3.6 ...

The output of this shows you detail that you're not interested in. Note that it's not truly recursive as otherwise you'll see the contents of sub-directories.

There are a couple of ways around this, as @steeldriver mentioned in comments using -d or --directory will only give directory names instead of contents:

ls -d pyth*

Alternatively you can use the find command using -maxdepth 1 to ensure it does not descend into subdirectories. Note the -name argument is quoted so that it's expanded by find and not by the shell.

find . -maxdepth 1 -name 'pyth*'

It's often better to use find than ls if you're going to rely on the output of a command for further processing as ls can give unexpected results in some circumstances.

edited Mar 11 at 18:13

answered Mar 11 at 18:05

Arronical

13.6k84993

Thanks for the thoughts, however, it gets a little more confusing as when I us ls (or ll) to list gcc(s) in /usr/bin, it does exactly what it's supposed to do. I get a nice list of the links and am able to look at the whole list and that is all that comes up.

– Mitch Oldroyd
Mar 11 at 18:19

@MitchOldroyd the difference there is that they are all files not directories, ls will give you directory contents but not file contents.

– Arronical
Mar 11 at 18:50

I guess I was not really making myself clear... I was typing ls, or l, or ll, or ls -a, or ls -l but never ls -R, but every time, it was taking me inside sub-directories but not just listing the contents of the folder. I was trying to repair links erroneously made by a script that someone wrote for me, but with ... (not for this conversation)... at any rate, I simply couldn't get what I was looking for. At any rate, I re-booted and it just went away. I re-booted because of changes I also made to .bashrc (call be weird, but having it re-run the bashrc script lengths paths unnecessarily

– Mitch Oldroyd
Mar 11 at 18:59

OK, more comment... I just rebooted, and it's back. everything is recursive again.

– Mitch Oldroyd
Mar 11 at 19:41

OK, one further refinement... turns out that they only default to recursive when listing from /usr/lib... either side of that, or down a different tree, and it all works like it should.

– Mitch Oldroyd
Mar 11 at 20:37

|
show 3 more comments

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
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1124838%2fterminal-command-ls%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

The output you're getting is because you're using shell pattern matching (globbing) of pyth* and running the ls command on each element output by the glob.

The shell returns the python3 and python3.6 directories first along with any other matches. They are used as arguments to ls so your command ends up as

ls python3 python3.6 ...

The output of this shows you detail that you're not interested in. Note that it's not truly recursive as otherwise you'll see the contents of sub-directories.

There are a couple of ways around this, as @steeldriver mentioned in comments using -d or --directory will only give directory names instead of contents:

ls -d pyth*

find . -maxdepth 1 -name 'pyth*'

It's often better to use find than ls if you're going to rely on the output of a command for further processing as ls can give unexpected results in some circumstances.

edited Mar 11 at 18:13

answered Mar 11 at 18:05

Arronical

13.6k84993

Thanks for the thoughts, however, it gets a little more confusing as when I us ls (or ll) to list gcc(s) in /usr/bin, it does exactly what it's supposed to do. I get a nice list of the links and am able to look at the whole list and that is all that comes up.

– Mitch Oldroyd
Mar 11 at 18:19

@MitchOldroyd the difference there is that they are all files not directories, ls will give you directory contents but not file contents.

– Arronical
Mar 11 at 18:50

I guess I was not really making myself clear... I was typing ls, or l, or ll, or ls -a, or ls -l but never ls -R, but every time, it was taking me inside sub-directories but not just listing the contents of the folder. I was trying to repair links erroneously made by a script that someone wrote for me, but with ... (not for this conversation)... at any rate, I simply couldn't get what I was looking for. At any rate, I re-booted and it just went away. I re-booted because of changes I also made to .bashrc (call be weird, but having it re-run the bashrc script lengths paths unnecessarily

– Mitch Oldroyd
Mar 11 at 18:59

OK, more comment... I just rebooted, and it's back. everything is recursive again.

– Mitch Oldroyd
Mar 11 at 19:41

OK, one further refinement... turns out that they only default to recursive when listing from /usr/lib... either side of that, or down a different tree, and it all works like it should.

– Mitch Oldroyd
Mar 11 at 20:37

|
show 3 more comments

The output you're getting is because you're using shell pattern matching (globbing) of pyth* and running the ls command on each element output by the glob.

The shell returns the python3 and python3.6 directories first along with any other matches. They are used as arguments to ls so your command ends up as

ls python3 python3.6 ...

The output of this shows you detail that you're not interested in. Note that it's not truly recursive as otherwise you'll see the contents of sub-directories.

There are a couple of ways around this, as @steeldriver mentioned in comments using -d or --directory will only give directory names instead of contents:

ls -d pyth*

find . -maxdepth 1 -name 'pyth*'

It's often better to use find than ls if you're going to rely on the output of a command for further processing as ls can give unexpected results in some circumstances.

edited Mar 11 at 18:13

answered Mar 11 at 18:05

Arronical

13.6k84993

Thanks for the thoughts, however, it gets a little more confusing as when I us ls (or ll) to list gcc(s) in /usr/bin, it does exactly what it's supposed to do. I get a nice list of the links and am able to look at the whole list and that is all that comes up.

– Mitch Oldroyd
Mar 11 at 18:19

@MitchOldroyd the difference there is that they are all files not directories, ls will give you directory contents but not file contents.

– Arronical
Mar 11 at 18:50

I guess I was not really making myself clear... I was typing ls, or l, or ll, or ls -a, or ls -l but never ls -R, but every time, it was taking me inside sub-directories but not just listing the contents of the folder. I was trying to repair links erroneously made by a script that someone wrote for me, but with ... (not for this conversation)... at any rate, I simply couldn't get what I was looking for. At any rate, I re-booted and it just went away. I re-booted because of changes I also made to .bashrc (call be weird, but having it re-run the bashrc script lengths paths unnecessarily

– Mitch Oldroyd
Mar 11 at 18:59

OK, more comment... I just rebooted, and it's back. everything is recursive again.

– Mitch Oldroyd
Mar 11 at 19:41

OK, one further refinement... turns out that they only default to recursive when listing from /usr/lib... either side of that, or down a different tree, and it all works like it should.

– Mitch Oldroyd
Mar 11 at 20:37

|
show 3 more comments

The output you're getting is because you're using shell pattern matching (globbing) of pyth* and running the ls command on each element output by the glob.

The shell returns the python3 and python3.6 directories first along with any other matches. They are used as arguments to ls so your command ends up as

ls python3 python3.6 ...

The output of this shows you detail that you're not interested in. Note that it's not truly recursive as otherwise you'll see the contents of sub-directories.

There are a couple of ways around this, as @steeldriver mentioned in comments using -d or --directory will only give directory names instead of contents:

ls -d pyth*

find . -maxdepth 1 -name 'pyth*'

It's often better to use find than ls if you're going to rely on the output of a command for further processing as ls can give unexpected results in some circumstances.

edited Mar 11 at 18:13

answered Mar 11 at 18:05

Arronical

13.6k84993

The output you're getting is because you're using shell pattern matching (globbing) of pyth* and running the ls command on each element output by the glob.

The shell returns the python3 and python3.6 directories first along with any other matches. They are used as arguments to ls so your command ends up as

ls python3 python3.6 ...

The output of this shows you detail that you're not interested in. Note that it's not truly recursive as otherwise you'll see the contents of sub-directories.

There are a couple of ways around this, as @steeldriver mentioned in comments using -d or --directory will only give directory names instead of contents:

ls -d pyth*

find . -maxdepth 1 -name 'pyth*'

It's often better to use find than ls if you're going to rely on the output of a command for further processing as ls can give unexpected results in some circumstances.

edited Mar 11 at 18:13

answered Mar 11 at 18:05

Arronical

13.6k84993

edited Mar 11 at 18:13

answered Mar 11 at 18:05

Arronical

13.6k84993

answered Mar 11 at 18:05

Arronical

13.6k84993

answered Mar 11 at 18:05

Arronical

13.6k84993

Thanks for the thoughts, however, it gets a little more confusing as when I us ls (or ll) to list gcc(s) in /usr/bin, it does exactly what it's supposed to do. I get a nice list of the links and am able to look at the whole list and that is all that comes up.

– Mitch Oldroyd
Mar 11 at 18:19

@MitchOldroyd the difference there is that they are all files not directories, ls will give you directory contents but not file contents.

– Arronical
Mar 11 at 18:50

I guess I was not really making myself clear... I was typing ls, or l, or ll, or ls -a, or ls -l but never ls -R, but every time, it was taking me inside sub-directories but not just listing the contents of the folder. I was trying to repair links erroneously made by a script that someone wrote for me, but with ... (not for this conversation)... at any rate, I simply couldn't get what I was looking for. At any rate, I re-booted and it just went away. I re-booted because of changes I also made to .bashrc (call be weird, but having it re-run the bashrc script lengths paths unnecessarily

– Mitch Oldroyd
Mar 11 at 18:59

OK, more comment... I just rebooted, and it's back. everything is recursive again.

– Mitch Oldroyd
Mar 11 at 19:41

OK, one further refinement... turns out that they only default to recursive when listing from /usr/lib... either side of that, or down a different tree, and it all works like it should.

– Mitch Oldroyd
Mar 11 at 20:37

|
show 3 more comments

Thanks for the thoughts, however, it gets a little more confusing as when I us ls (or ll) to list gcc(s) in /usr/bin, it does exactly what it's supposed to do. I get a nice list of the links and am able to look at the whole list and that is all that comes up.

– Mitch Oldroyd
Mar 11 at 18:19

@MitchOldroyd the difference there is that they are all files not directories, ls will give you directory contents but not file contents.

– Arronical
Mar 11 at 18:50

I guess I was not really making myself clear... I was typing ls, or l, or ll, or ls -a, or ls -l but never ls -R, but every time, it was taking me inside sub-directories but not just listing the contents of the folder. I was trying to repair links erroneously made by a script that someone wrote for me, but with ... (not for this conversation)... at any rate, I simply couldn't get what I was looking for. At any rate, I re-booted and it just went away. I re-booted because of changes I also made to .bashrc (call be weird, but having it re-run the bashrc script lengths paths unnecessarily

– Mitch Oldroyd
Mar 11 at 18:59

OK, more comment... I just rebooted, and it's back. everything is recursive again.

– Mitch Oldroyd
Mar 11 at 19:41

OK, one further refinement... turns out that they only default to recursive when listing from /usr/lib... either side of that, or down a different tree, and it all works like it should.

– Mitch Oldroyd
Mar 11 at 20:37

Thanks for the thoughts, however, it gets a little more confusing as when I us ls (or ll) to list gcc(s) in /usr/bin, it does exactly what it's supposed to do. I get a nice list of the links and am able to look at the whole list and that is all that comes up.

– Mitch Oldroyd
Mar 11 at 18:19

@MitchOldroyd the difference there is that they are all files not directories, ls will give you directory contents but not file contents.

– Arronical
Mar 11 at 18:50

I guess I was not really making myself clear... I was typing ls, or l, or ll, or ls -a, or ls -l but never ls -R, but every time, it was taking me inside sub-directories but not just listing the contents of the folder. I was trying to repair links erroneously made by a script that someone wrote for me, but with ... (not for this conversation)... at any rate, I simply couldn't get what I was looking for. At any rate, I re-booted and it just went away. I re-booted because of changes I also made to .bashrc (call be weird, but having it re-run the bashrc script lengths paths unnecessarily

– Mitch Oldroyd
Mar 11 at 18:59

OK, more comment... I just rebooted, and it's back. everything is recursive again.

– Mitch Oldroyd
Mar 11 at 19:41

OK, one further refinement... turns out that they only default to recursive when listing from /usr/lib... either side of that, or down a different tree, and it all works like it should.

– Mitch Oldroyd
Mar 11 at 20:37

|
show 3 more comments

draft saved

draft discarded

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.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1124838%2fterminal-command-ls%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Cfxtrjtrk