I am reading a book regarding Unix/Linux commands and this here gets me into questions.

While I can use the output of a command as an expansion if I don't include a path in the ls part, including a path throws an error.

So file $(ls Pictures/ | grep zip) from the home directory results in error while changing to Pictures/ beforehand doesn't.
So, using file $(ls | grep zip) works fine.

http://cl.ly/2L0R2u431M3h442L051v

I'm using Ubuntu 10.04 LTS if that has something to do with it.
Thanks in advance.

When the argument of ls is a directory, the directory content is displayed and each file is listed without its actual path. In many circumstances the usage of ls can be avoided in favor of shell's globbing capabilities, e.g.

Thank you very much. Yeah, that was kind of example taken from the book and wanted to know if I'm doing it wrong or that the example is wrong.

Hi, welcome to LQ!

Just a word of advice: for your intents you would have been better
off using copy & paste from a terminal into a
block.

No external links, no uploads, much faster.



Cheers,
Tink

I'll keep that in mind

Also note thet it's almost always a bad idea to parse the output of ls, and it's never necessary.

This command is doing three things.

First, the ls command outputs the contents of the Pictures directory.

Then grep searches for lines from that output that match "zip". There can be zero, one, or more filenames.

Finally, the file command attempts to read those names that grep matches.

So try running each step in turn and see what you come up with.

Well, it turns out that the problem is with the output of ls. "ls Pictures/" gives you a list of filenames inside Pictures, but without the full path included. That is, you're getting file.zip when you really need Pictures/file.zip. So when file tries to read them, it looks in your present working directory for them and comes up with a missing file error.

You've just discovered, as MTK358 mentioned, one reason not to parse ls for filenames.

http://mywiki.wooledge.org/ParsingLs