LinuxQuestions.org - [SOLVED] How to Prevent Error from ls Command?

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - How to Prevent Error from ls Command? (https://www.linuxquestions.org/questions/linux-newbie-8/how-to-prevent-error-from-ls-command-4175524458/)

How to Prevent Error from ls Command?

Hello All,

SHELL: Bash v4.1.10(1)
ls --version: ls (GNU coreutils) 8.9

From the ls man page it says you can use "ls -1" (*that's a "-" and a number ONE) to list the files in a directory, one file per line.

The command works just fine entering it on the command line like "# ls -1", but when I try to use it with the $(..) structure along
with IFS=newline I get an error and then ls stops working until I open a new terminal window...

For Example:

Code:

# ls -1

file 1

file 2

myDir 1

file 3

file 4

myDir 2

....etc....

But when I use $(..) and IFS=newline I get an error and ls stops working in that terminal all together...

Code:

# IFS="

"

# ARRAY=( $(ls -1tr) )

ls: invalid option -- ' '

Try `ls --help' for more information.

#

# ls

ls: invalid option -- ' '

Try `ls --help' for more information.

So it only seems to throw that error when I set IFS to a newline... Any idea why that would be happening? For some reason I thought
I also got that error when executing from inside a script, but it doesn't seem to cause an issue inside my bash script, just on the CLI.

Any thoughts or suggestions would be much appreciated!

Thanks in Advance,
Matt

Works just fine on my systems on bash 4.1.2, 4.1.7, and 4.3.26. What distro/version are you using?

it works for me using bash 4.3.30 and believe me it is not a bug of ls, but probably a bug of bash - because it parses the command line incorrectly and passes something "strange" to ls.
Remember, at first always the shell itself tries to understand what you entered, tries to expand some possible variables and finally the result will be passed to the command.
you may try to use strace to check that.

Hey Guys, thank you both for the replies...

Did you both make sure to set IFS to a newline, otherwise you won't get the error...
Like this:
---------
IFS="
"
---------

I know its older but I'm running:

Code:

> bash --version

GNU bash, version 4.1.10(1)-release (i586-suse-linux-gnu)



> uname -a

Linux *.local 2.6.37.6-0.20-default #1 SMP 2011-12-19 23:39:38 +0100 i686 i686 i386 GNU/Linux



> cat /etc/*release

openSUSE 11.4 (i586)

VERSION = 11.4

CODENAME = Celadon

Yea, I was thinking that some how the 1 is being parsed or something like that because of the ( $(..) ) but wasn't
too sure. And also it ONLY happens when I set IFS to a newline... It also happened to me on a server running Bash 3.1.17..

But, since it seems to work just fine in my Bash script I'm not too worried about it, I was just curious why something like that
would be happening.

Thanks again for the replies, much appreciated!

Thanks Again,
Matt

Quote:

Originally Posted by mrm5102 (Post 5265125)

Hey Guys, thank you both for the replies...

Did you both make sure to set IFS to a newline, otherwise you won't get the error...
Like this:
---------
IFS="
"
---------

On one of my CentOS 6.6 systems:

Code:

$ bash --version

GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>



This is free software; you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.



$ IFS="

> "

$ echo $IFS



$ ARRAY=( $(ls -1tr) )

$ echo ${#ARRAY[@]}

55

$ echo ${ARRAY[0]}

bin

$ echo ${ARRAY[1]}

mplayer

Is it possible you have an alias or function defined for ls that might be interfering? What if you run:
ARRAY=( $(\ls -1tr) )

Hey, thanks again for the reply!

Yes sir... That did work and did NOT throw any error!

And yes, there are a few aliases setup for ls.

Code:

alias l='ls -alF'

alias la='ls -la'

alias ll='ls -l'

alias ls='ls $LS_OPTIONS'

alias ls-l='ls -l'

So you think that was the issue?

Thanks AGAIN,
Matt

Definitely. It must be something in $LS_OPTIONS that's messing things up. The backslash in front of the command forces it to skip any aliases and run the "real" command, eg:

Code:

$ alias ls="echo"

$ ls "hello there"

hello there

$ \ls "hello there"

ls: cannot access hello there: No such file or directory

Ok cool... That's good enough for me!!

Thanks for the explanations much appreciated, that was bothering the heck outta me..!

Thanks AGAIN,
Matt