Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Use lsmac to get Mac file information in the Terminal UNIX
Sveinbjorn Thordarson sent me an email detailing his new, free, open source, "Mac compatible" version of ls, lsmac. Here's what he had to say about it:
Thought you might be interested to know I've made a command line unix program similar to ls but with a Mac twist. It's called lsmac (48K download), and it sports the following features:
  • Lists the files within a directory
  • Can display file size in human-readable format (i.e. 1.2MB instead of 12759024 bytes)
  • Displays the size of all the file's forks, including the heritage resource fork, not just the data fork like ls!
  • Displays file and creator types
  • Displays the Finder flags that are set
Apple supplies command line utilities with the Developer Tools that share some of this functionality, but they operate on a single file basis. lsmac is free, open-source GPL'd software.
I tried lsmac this morning, and it works as described. Sveinbjorn provides two ways to install lsmac, using either a shell script installer or via a source compile. I tried both, and though they both worked, the shell script install automatically gives you the man page, which you otherwise need to copy by hand. The shell script installs lsmac in /usr/bin, but it's a two-second edit to point it elsewhere if you prefer (I used /usr/local/bin). Here's a small snippet of the output:
% lsmac
-C----  8BPS 8BIM    201 KB  2002NewYear.psd 
------  JPEG 8BIM     21 KB  2003newyear.jpg 
------  TIFF ogle      7 KB  999 mark.tiff 
------  JPEG 8BIM    211 KB  bday_big.jpg 
-C----  8BPS 8BIM    1.7 MB  birthday2.psd 
-C----  JPEG GKON    119 KB  calendar.jpg 
------                47 KB  calendar.tiff 
------    4 items      -     Classic Scripts/ 
------  ???? ????      3 KB  config.php 
------    2 items      -     docs/ 
------  ???? ????     18 KB  english.php 
------  TEXT R*ch      1 KB  example of posting code 
------                11 KB  FAQ text.txt 
------  XLS8 XCEL     12 KB  forum activity.xls 
------  XLS8 XCEL     19 KB  forum stats.xls 
Getting the human-readable size is an added bonus (though I'd already installed new 'df' and 'du' commands to do that), and I really like seeing the type and creator info in the directory list. Definitely worth a look if you spend much time working with Mac files from the Terminal.
    •    
  • Currently 3.67 / 5
  You rated: 5 / 5 (3 votes cast)
 
[10,577 views]  

Use lsmac to get Mac file information in the Terminal | 34 comments | Create New Account
Click here to return to the 'Use lsmac to get Mac file information in the Terminal' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Use lsmac to get Mac file information in the Terminal
Authored by: johnfountain on Apr 09, '03 10:40:05AM

This works mostly as expeted for me, however, i have a few diectories where it returns a partial list and an error:

FSPathMakeRef(): Error -35 returned when getting file reference from path

-john



[ Reply to This | # ]
Use lsmac to get Mac file information in the Terminal
Authored by: luhmann on Apr 09, '03 11:36:10AM

Me too - and I don't get proper listings as shown above, just lots of dashes and blank spaces.



[ Reply to This | # ]
Read the manpage
Authored by: gidds on Apr 09, '03 11:55:49AM
From the manpage: By default, lsmac does not display file size and only lists the file name.  (You did read the manpage, didn't you?)  Those dashes you see are probably the flags; if the file isn't invisible, locked, stationary, an alias, a bundle, or with a custom icon, then you won't see any letters there.

Try one or more of the options:

  • -s Display file size in human-readable format (i.e. 1.2MB or 327KB)
  • -b Display file size in bytes (i.e. 12977128 bytes)
  • -o Omit folders when listing directory contents
  • -a Display all files, including files with the . prefix.
  • -p Display full file paths instead of file names
  • -l When listing file size, use physical size instead of logical size.

---

Andy/

[ Reply to This | # ]

Read the manpage
Authored by: luhmann on Apr 09, '03 03:07:55PM

So the above example should read:

% lsmac -s

not just

% lsmac

correct?

Anyone know why it produces the "FSPathMakeRef(): Error -35 returned when getting file reference from path" errors?



[ Reply to This | # ]
1024 bytes
Authored by: englabenny on Apr 09, '03 11:46:52AM

Hm the normal -s output of lsmac outputs the sizes in 1000 bytes' kilobytes and 1 million bytes' megabytes. And, also the -sl option does to. On a 300 kb file this leads to an error of ~5kb. So why whine? I want it do display correctly! :D

Why? I think I'll change the code, where I can see he uses byteCount/1000 to get kiloByteCount.

But hey - thanks for open Source!



[ Reply to This | # ]
1024 bytes
Authored by: Hes Nikke on Apr 09, '03 02:54:35PM
i see the proper 10^X byte prefixes on KB, and MB (for once)

perhaps your looking for the 2^X MiB, and KiB?

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.

[ Reply to This | # ]

1024 bytes
Authored by: englabenny on Apr 09, '03 03:53:22PM

Yes I do, because that's the way to correctly display file size, or atleast the way Finder does it. Eventhough they call 'em KB and not KiB.



[ Reply to This | # ]
why would you want base-10 sizes?
Authored by: Lizard_King on Apr 09, '03 06:17:32PM

This is definitely not a flame, just an academic question ;-)

I'm just trying to understand why you would want to see file sizes (or any other system metric) in decimal. Systems are inherently binary by nature so representing this information in any other base besides base-2 would be inaccurate.

I guess I could see if you are trying to do approximations and require quick math, that might suffice... any insight for me?



[ Reply to This | # ]
why would you want base-10 sizes?
Authored by: Hes Nikke on Apr 09, '03 10:03:47PM

did you read the link?

the link explains all about Mega, and Mebi, and why the computer industry applied non-standard difeninitions to terms that are standard every else.

you're right, they noticed that 1 KiB and 1KB were almost the same (1024, 1000) and that is were all our trubbles bagan

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.



[ Reply to This | # ]
1024 bytes
Authored by: Hes Nikke on Apr 09, '03 11:05:26PM

and here is the <a href="http://programming.ForgottenNewbies.com/~natef/lsmac 0.3.1.tar.bz2">bug fix</a> this is version 0.3.1, it's been emailed to the auther, but it isn't official yet. the changes since 0.3.0 are:

* lsmac human readable format is now base2 (MiB) rather then base10 (MB)
* added -B switch to show in base10 (MB)
* for more info on MiB see http://www.wikipedia.org/wiki/Byte_prefixes
* posibly fixed a bug with the physical size setting (was checking for the -l switch and then ignoring it)

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.



[ Reply to This | # ]
1024 bytes
Authored by: Hes Nikke on Apr 09, '03 11:06:46PM
hmmm.. i could sware i saw a clickable link when i did that preview...

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.

[ Reply to This | # ]

Use lsmac to get Mac file information in the Terminal
Authored by: bluestar on Apr 09, '03 11:50:20AM

Why a separate tool? Why not patch the GNU ls with fork, type and Finder support?

The -M option is still available.



[ Reply to This | # ]
Re: ls patch
Authored by: bmerlin on Apr 09, '03 02:10:56PM

Maybe because the author didn't want to.

Why don't you?



[ Reply to This | # ]
Use lsmac to get Mac file information in the Terminal
Authored by: carsten on Apr 09, '03 06:18:02PM

Unfortunately it is not a trivial task to simply patch GNU's "ls" source code to add type/creator codes and resource forks, but hopefully sometime in the future it will be possible. :)

Anyone with sufficient programming experience should probably e-mail the author directly if he/she can help with this endeavour, IMHO it would be *very* nice for the Mac platform to have GNU "ls" compile with such type/creator/rsrc features "out-of-the-box!"

Carsten



[ Reply to This | # ]
great idea!
Authored by: sgi_oh_too on Apr 09, '03 11:30:29PM

even though it is "hard" to patch gnu ls ... it should have been done that way ... creating single purpose apps that have features that should be included in existing projects is what makes open source so ridiculous these days. Have you ever looked on freshmeat at the number of text editors out there? 400+ ... there is absolutely no reason for that. These features should be rolled into gnu ls ... and that is that. Perhaps ill do just that later this week and post it up here.



[ Reply to This | # ]
it *should* have been done that way
Authored by: semios on Apr 10, '03 02:38:59PM

I guess you would also claim that there are far too many books on philosophy in the library? There is absolutely no reason for all those books.



[ Reply to This | # ]
it *should* have been done that way
Authored by: sgi_oh_too on Apr 11, '03 12:27:53AM
good response ... although, software development is an entirely different thing

there isn't much gain in having a single book that covers all the bases over a group of books that covers all the bases ... but having a single application that covers all the bases is essential because it contributes to overall productivity, ability, and ease of use

imagine having one web browser that displays the text and jpgs of a web page ... and another web browser that displays the text and gifs of a web page

or even worse ... having one powerful app to list the files and attributes in a directory, and another that offers different attributes but is much less powerful ... thus forcing every listing of a directory to be %ls followed by %lsmac ... this is not simple, elegant, nor intuitive

having multiple (overlapping and/or redundant) books is simply not comparable since the purpose of philosophy books is to explain concepts/ideas/rationale rather than rotely format and organize information in a "simple" and "quick" manner

[ Reply to This | # ]
Use lsmac to get Mac file information in the Terminal
Authored by: ClarkGoble on Apr 09, '03 03:14:49PM

Does it support color in the terminal?



[ Reply to This | # ]
lsmac errors
Authored by: sveinbjorn on Apr 09, '03 05:34:26PM
I'm the author of lsmac. I posted this "hint" a while ago and in the meantime lsmac has gone up to version 0.3, which should fix a lot of those "Error -35: getting file reference from path" errors. Also, file size is listed by default (in human readable format) in this new version.

Lots of additional features are planned, so stay tuned. If you have Fink installed, you should be able to keep up with the latest release since lsmac is part of the Fink "unstable" group of packages.

[ Reply to This | # ]
lsmac errors
Authored by: gmackenz on Apr 09, '03 06:45:02PM

I don't see lsmac in fink. I did 'link apropos lsmac' and the search returned nothing. What am I doing wrong?



[ Reply to This | # ]
lsmac errors
Authored by: at_sym on Apr 09, '03 08:11:58PM
He said it's in the unstable tree, so unless you've added unstable/main and unstable/crypto to your Trees: line, you won't see it. Here's how to install a package from the unstable tree.

[ Reply to This | # ]
Use lsmac to get Mac file information in the Terminal
Authored by: gmackenz on Apr 09, '03 06:57:04PM
Actually the more current link is this: version 0.3

[ Reply to This | # ]
Use lsmac to get Mac file information in the Terminal
Authored by: luhmann on Apr 10, '03 12:29:50PM

version .3 still gives errors:

FSPathMakeRef(): Error -35 returned when getting file reference from //dev

however, it doesn't choke the rest of the output.



[ Reply to This | # ]
Use lsmac to get Mac file information in the Terminal
Authored by: notmatt on Apr 10, '03 03:58:09AM

Personally, I find the whole 1000 vs. 1024 argument to be entirely irrelevent. Seriously, noone suggests I buy I some cheddar and a trap when I say my Mac is has a mouse problem. The meaning is perfectly comprehensible in the context of the statement. Likewise the 1000/1024 nonsense.

The far more important distinction is not some arbitrary decision on technical correctness, but rather the Law of Least Astonishment; the program should produce the output that least astonishes the user. In this case, that should mean the binary interpretation of the prefixes.



[ Reply to This | # ]
A kB by anyother name...
Authored by: IslandDan on Apr 10, '03 09:21:00AM

The Law of Least Astonishmen would be that kB and MB would be 1,000 and 1,000,000 conforming to everything not computer and most things computer such as communication speeds, USB speeds, FireWire speeds, bus speeds, cpu speeds, disk drive sizes, etc. How long should it take to transfer 1Mb over a 1Mb/s communications channel? 1 second?

It is least astonishing that 1 kB, 1 kg and 1km are 1,000 base units. It is least astonishing that 1KB is 1024 bytes and 1MB is 1,048,576 bytes and 1GB is 1,073,741,824 bytes only to techno geeks.

Computers should conform to common and expected standards or people, not people to computer memory manufacturing methods.



[ Reply to This | # ]
A kB by anyother name...
Authored by: carsten on Apr 10, '03 01:24:33PM

As memory and hard drives are becoming increasingly larger, I expect the computer industry will eventually switch from binary size notation (i.e. 1024) to metric (1000), as the disparity bewteen an actual count of bytes represented by each notation increases with ever-greater size measurements.

For now it seems, the only ones who consistently use metric byte notation are hard-drive manufaturers.

Seriously, until such time as hard drives and memory size grow so large that the computer industry is forced to switch over from binary byte notion to metric byte notation, I suggest a more profitable expenditure of "metrification" efforts would be to encourage the general adoption of S.I. units everywere in North America, as most of the world already employs.

Particularly the lack of use of A4 paper bothers me personally, the infinite benefits of metric paper sizes seem to be lost on us Canadians (we primarily use standard metric but also use Imperial units for many things) as well as our American friends. See ISO paper

:)
Cheers,
Carsten

[ Reply to This | # ]

A kB by anyother name...
Authored by: WillyT on Apr 13, '03 08:27:11AM

To me a 45 year computer user:

1 kB = 1000 bytes
1 KB = 1024 bytes

1 kb = 1000 bits
1 Kb = 1024 bits

Due to the way serial data is transmitted 50Kb/sec is approx 5kB/sec.
(1.5 start bits + 7 or 8 data bits + 0 or 1 parity bit + 1 or 2 stop bits = somewhere in the neighborhood of 10 or 11 bits)

Of course I learned things in the "wrong order":
English
Latin
Fortran IV
Ladder Logic
Machine Language
Assembler Language
Basic
C
Logo
Forth
Lisp
Boopsi
C++
Objective C

I don't claim to be any good at any of these (I'm just a user who has a dealer and I can do my own fix).

I program in Ladder logic.



[ Reply to This | # ]
A kB by anyother name...
Authored by: WillyT on Apr 13, '03 08:36:49AM

Oops I'm not that old I can't even count on my fingers. I've been using computers for only 35 years.



[ Reply to This | # ]
Use lsmac to get Mac file information in the Terminal
Authored by: Hes Nikke on Apr 10, '03 01:38:18PM
i don't know if you saw this above, but i have a tweeked version of lsmac that properly deals with MB's and MiB's

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.

[ Reply to This | # ]

lsmac - improvements
Authored by: sveinbjorn on Apr 10, '03 01:37:49PM
Hi again, everyone,

I'm very happy about the response that lsmac has generated and it pleases me that it is filling a useful niche. Many people have mailed me suggestions for improvements and I'm taking them into consideration. Others have been kind enough to send me their own improvements and optimizations to the code. As I write this, I'm adding their changes to make a 0.4 release.

Regarding suggestions that I add lsmac's features to the standard ls, either the GNU ls or the Darwin file_cmd versions, I have no plans to do so. I looked into it a while ago, and found that it would require quite a lot of programming work of the kind that I'm not particularly interested in. Of course, anyone is free to undertake this. Meanwhile, I'll continue to improve and add features to lsmac.

I'll put up a web page for lsmac where I'll list recent developments. If you want to be notified of new releases, then just email me and I'll add you to a list.

Thanks to all of you for your feedback.

[ Reply to This | # ]
lsmac - improvements
Authored by: Hes Nikke on Apr 11, '03 04:33:29AM

hmmm http://www.raunvis.hi.is/~ssv/lsmac.html returns a 404

---
vacuums do not suck. they merely provide an absence that allows other objects to take the place of what becomes absent.



[ Reply to This | # ]
installing with fink
Authored by: wgscott on Apr 10, '03 03:37:09PM

I just installed version 0.3 with fink. The .info file installs 0.2, so I had to edit it. Any chance you can update the fink .info file for the distribution?

Apart from that (and the checksum needing updating) it works great with fink.



[ Reply to This | # ]
installing with fink
Authored by: carsten on Apr 13, '03 02:43:55PM

0.3 is in fink unstable now, cheers



[ Reply to This | # ]
lsmac is now osxutils
Authored by: carsten on Jun 02, '03 03:50:48PM
lsmac is now part of a greater package called osxutils. See this updated hint about osxutils.

[ Reply to This | # ]