Dumping file names with ls
 

I'm not a unix newcomer (been using linux for 5 years), but I am a mac newcomer.

I've used the command ls *.(file_extension) > text.file (or some variant thereof) forever with no problem on linux. Yet, when I attempt the same thing on my mac I get a text.file with formated text (more/less says 'file may be a binary file), which really wrecks havoc when trying to parse lines from text.file.

Why is the text formatted? What do I need to do to get plain text dumped to text.file? I've tried searching for answers, but nothing obvious is coming up.

Thanks.

What are you opening the file with, and have you tried this?

ls *.(file extension) > text.txt

Doesn't matter
 

It doesn't matter what I open it with (it shouldn't matter either). What I want is unformatted text, but I get this type of stuff

What I want to see (and what I'm used to seeing on linux) is the following:

(I copied the second output from the linux box sitting next to me after running the same command). Any thoughts?

Please copy & paste the following commands into a newly opened Terminal window (I'm assuming that you are using Terminal.app - is that correct?) and then press Return and then copy & paste the whole contents of the Terminal window back here so we can see:


/bin/ls *.img | /usr/bin/vis
/bin/ls *.img > files.txt
/usr/bin/hexdump -C files.txt

Perhaps ls is defined as a function or an alias:

type -a ls

?

Here's the output:

Does this provide you a clue?

why not use the open command?


Just tested it and it works for me.

That seems to show that everything is completely normal.
Look at that files.txt file with any text editor and you should see that it is as you would expect.
So I think the problem is with your 'ls' or 'more' commands - maybe (as Hal Itosis suggested) one or both of these is actually an alias or a function.
What do you get from:

type -a ls
type -a more

You are getting colorized output in your file for some reason. I have color turned on as well, but it doesn't do it while I write a file. Are you forcing ls colors somehow?

Unfortunately everything is not normal. If I open the file in (fill in blank with favorite text editor, I tried several) I get this:

Something is definitely wrong. I originally realized there was a problem with I tried to parse the text file in idl. I'm trying to read in the file, line be line, as strings, but it can't be interpreted as a string with the extra formatting characters.

I'm really confused as to what's going on here.

ataraxia: Yes, I do have have ls aliased to show colors, but if I disable the alias I still get the garbled output.

Is your character set encoding Unicode (UTF-8)?

Why have you not responded to Hal Itosis and hayne's queries? Please do so.

Trevor

Sorry - which file is this?
I was speaking of the file "files.txt" that held the output of the '/bin/ls' command.
It looks like you are still looking at the output of your (alias for) 'ls' command.

The hexdump output you showed above makes it clear that the "files.txt" file is correct.

So, I repeat, the problem is with whatever alias you are using for 'ls'.

By the way, note that it is a bad idea to use the name of an existing command for an alias - i.e. to try to replace an existing command with an alias. You should use a different name for your alias - e.g. something like 'lsc', so that it is clear that this is not the standard 'ls' command.

When I need to out put something to a text file from terminal I typically use the open command, and since I dislike textedit over other text editors I use the -a switch followed by the application name.

example

That will output everything right into text wrangler and I can attach it to an email or what not and send it out.

Unless you want to edit the text file, there is no reason to use 'open' to create the text document in an application.
The simple use of '>' to redirect the output to a file (as in the topic of this thread) is sufficient to create the text file wherever you choose.

Problem solved!

I just talked to our system admin, and he said this wasn't the first problem that had been reported today involving commonly used command line tasks and he traced the problem back to a corrupt file that was improperly patched over the weekend on our mac server.

Apparently my issue was relatively tame in comparison to things that other people were dealing with.

Thanks everyone for the help.

Maybe for the benefit of future readers (and to satisfy my curiosity), you could explain how this "mac server" was involved in the commands you showed above.
Is your home folder on this server (as opposed to being on the local Mac)?
Were you remotely logged into this server?
And why didn't the problem on this server affect the commands that I suggested (in post #4) which worked correctly?

I just like the pretty colors that textwrangler puts the fonts in and I like to choose where to save it, I keep different things in different directories and the GUI for me makes it easier.

It is just a preference is all.

It was a combination of various factors:

IDL is run from the main server (that way we only need one license), so I was ssh-ed into the server and the problem resided on the server. I was using my own local machine terminal when I entered the commands you suggested in post #4 and therefore using my own machines /bin/ls, etc. For the time being I'm now able to create my files.dat, then ssh into the server, then run IDL (on my server home folder) using the now correct files.dat.

I guess that it is my own fault for not perfectly recreating the situation when you asked my to run those commands.

Do this
 

here is the solution I use.

instead of

ls *.txt

add a slash:

\ls *.txt

it appears that ls is alaised somehow to run through a formatter. Using the slash causes it to use the unaliased generic ls.

The "somehow" must be something that you configured (in the shell "dot" files - see the shell config section of this Unix FAQ)
or something that you installed.

That's pretty neat (and news to me anyway).
I knew about the "command" command (for bypassing shell builtins and/or user-defined functions in scripts).

But why does the \backslash work?
Doesn't appear to be a keyword...
$ type \
>
[^C]
$ type \\
-bash: type: \: not found

$ type '\'
-bash: type: \: not found

--

Hmm, apparently the \ has the same effect as *quoting* the text.
So, typing...
'ls'
would have the same effect: bypass the alias and run the standard utility.

Still not clear why that works tho.

The page http://www.chiark.greenend.org.uk/~s...m/aliases.html (about special uses of aliases) explains:

Interesting page!

I can relate to his "find" example there.
For a few scripts, i've even used this heading:
#!/bin/bash -f -
to kill globbing within the whole script... so that stuff like "*.txt" can be
passed to internal functions without expanding (if something in the cwd
happened to match).