Sorting files in BASH
 

I've been trying to find an answer to this all night with no luck. Maybe i've been looking in the wrong place. Anyway is the a way in BASH to sort files by upper or lowercase letter.

For example, list all files beginning with an uppercase.

Any help would be appreciated.

See "man ls".

By default, ls sorts in alphabetical order ignoring the case of the file name.

To list all files starting with a capital letter, you need to use a regular expression, such as (I haven't tested this): "ls [A-Z]*"

I hope this helps
--Ian

hmm, "ls [A-Z]*" does not work.
I'd think it'd be something like: ls --ignore [a-z]*
but that does not work as well ..

I think you'd be better off sticking the output from ls into a pipe and letting another program sort it. There is, of course, the sort utility for sorting, but I can't see any concept of character case (from its man page at least), and you already have a case-insensitive sort. The first thing that comes to mind is grep - a simple pipe likewill acheive what you want. Apparently grep is pretty resource intensive, and I doubt you need its power for something like this, so there are probably better tools. sed and awk also spring to mind - though sed would basically be emulating grep as inand awk is probably even more intensive than grep.

Anyway, that's really just an aside as I don't think a standard desktop would notice the performance hit of grepping the output from ls. Though I'll admit it would be nicer to specify an argument to ls itself, so you can play around with columns (either manually or by specifying the -l argument) without having to worry about your output format. If it's important that you can do this, it shouldn't be too tough to write a script that looks at its input to work out what columns it has in what order, and sorts on the filename.

@Dtsazza: that's weird, your first solution does the same as for me as: ls
The second one works as supposed though.
Have you tried that first one yourself?

Thanks for the input guys. Dtsazza the grep pipe is perfect cheers.

I suppose it will take a while to move from gui based thinking to shell style thinking.

Thanks again.

can someone tell how i can find out why this grep command is not working for me:?
(just trying to learn something here ..)
thanks! I copied it from the commandline, so it can't be typo's.

But those work perfetcly. Those commands worked for me properly in RedHAT 9 with bash

yeah, that was why i was wondering why this is not working in my shell :?
cat /etc/passwd shows i'm running /bin/bash
I'm working under suse 10.0
If somebody knows how i can find out why
does not work for me (see post above), please let me know :)

That is rather strange, and I tested the command as working before posting it (always good to check, if only for typos). Looking it your command, I can't see why it wouldn't work... it rather straightforward-ly says "OK, match the start of the line, followed by one of the characters A..Z".

As a test, can you tryandto see if it's the caret or the range that's causing the problem (both of these should just output NEW.TXT)? Also, it might sound obvious, but is NEW.TXT all uppercase ASCII characters? If you're using a Unicode shell and the filename was generated in some way other than you typing in it's name yourself, there's a chance the characters won't be in the range U0041-U005A ('normal' uppercase characters) but will look the same. Yep, it's unlikely, but then that grep really should be working...

it's still weird, the minus in ^[A-Z] doesn't work properly.whereas with sed it does work:

That's really weird. My first thought was that maybe it wasn't recognising the dash as a special character - but it is more than just a literal, because of the difference between 'grep ^[NZ]' and 'grep ^[N-Z]'. It seems that it's interpreting it as a case-insensitive range.

My thoughts are that perhaps your shell's locale is defining some kind of default search order that either makes all ranges case-insensitive, or somehow inserts a-z between A and Z (less likely). But then, it's weird that sed doesn't use the same information to process its own regexes. Besides, I'm no good at locales, so moving swiftly on...

I think acould be interesting at this point.

thanks for thinking along. I'm still just trying to make sense of linux so ..
I have no real problem atm but am just trying to learn.

according to 'man setlocale', LC_COLLATE="en_US.UTF-8" and LC_CTYPE="en_US.UTF-8"
are the ones defing regexp. But they look pretty standard to me. Maybe LC_ALL= should also be defined :?

/edit: ahhh! It is indeed LC_ALL which should be set to LC_ALL=C
as explained here: http://www.linuxquestions.org/questi...hreadid=327916

/edit: to change this setting to LC_ALL=C do
Thanks to Dtsazza for the hints! Funny to see that the behaviour of ls -all has changed accordingly to the LC_ALL setting.
And also that suse 10.0 has LC_ALL= not set to C as standard for me.

Wow... I didn't know that myself, so thanks for taking my vague hints and making them into something workable! I've got the exact same version of grep so it really must be something else. And my LC_ALL variable is also unset, so it wasn't that.

Still, if we've got something that sorts in 'ls' itself, that's much better than piping to grep, both from a resources point of view and so you can play around with ls switches and still get what you want.

Besides LC_ALL it can be other 'locale' settings as well: from man grep:
Pretty complex with all the or, or, ors :p