Live data from Hacker News

Apple's libc shells out to Perl to implement wordexp

github.com

11–20 of 49 posts

Re: Apple's libc shells out to Perl to implement wordexp

#11
post #10
post #6

This is source code from 2011. Checking http://opensource.apple.com will show that it's not longer implemented this way in 10.10. Here's the current implementation: http://opensource.apple.com/source/Libc/Libc-1044.1.2/gen/Fr...

Can you explain why wordexp.c on the referenced site has a completely different (and older) copyright? Did they merge in another implementation?

I'm guessing that the linked implementation probably hadn't been touched since 2008. My comment that this was source code from 2011 was referring to the fact that this release of libc (Libc-763.11) is from 2011.

Re: Apple's libc shells out to Perl to implement wordexp

#12
post #8

They appear to be using a "wordexp-helper" in Yosemite. I found this in /usr/lib/system/libsystem_c.dylib (and no references to perl). [ $# -gt 0 ] && export IFS="$1";/usr/lib/system/wordexp-helper

Source to wordexp-helper here: http://opensource.apple.com/source/system_cmds/system_cmds-6...

Also the source to the Yosemite implementation is available at: http://opensource.apple.com/source/Libc/Libc-1044.1.2/gen/Fr...

Re: Apple's libc shells out to Perl to implement wordexp

#13
post #3

Well, you are warned: /* XXX this is _not_ designed to be fast */

Performance is the least of my worries here. I'd be more worried about security, and plain dependency management.

I mean, let's say this libc thing is supposed to be installed in quite a lot of systems, are we really sure that perl thing is installed in all of those systems? And what if, by some crazy coincidence, perl happens to depend on libc?

Re: Apple's libc shells out to Perl to implement wordexp

#14
post #5

As it's already written in the manual... http://linux.die.net/man/3/wordexp wordexp, wordfree - perform word expansion like a posix-shell So, the implementer decided to take the short route, and just spawn a shell which, essentially, gets passed the input data to wordexp(), to do the work. But, of course, having something that starts with such a comment... /* XXX this is _not_ designed to be fast (...) wordexp is als…

Scroll down, there are many more gems in the comments!

...and what a spelling errors:

"This kludge is needed because /bin/sh seems to set IFS to the defualt even if you have set it; We also can't just ignore it because it is hard/unplesent to code around or even a potential security problem because the test suiete explicitly checks to make sure setting IFS 'works'"

ESR writes about sloppy spelling: "Write in clear, grammatical, correctly-spelled language. We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding (often enough to bet on, anyway)."

Re: Apple's libc shells out to Perl to implement wordexp

#15

Sorry, I don't have a Mac to check, but does the OSX build of Perl depend on libc? Also, that code seems to be from 2008 (or at least that's the latest year in the copyright header) despite the commit being from 2012. Does anyone know if this has been updated? Inserting a NUL byte between each word, and at the end doesn't sound like it requires Perl...

> otool -L /usr/bin/perl

/usr/bin/perl:

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1151.14.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

Re: Apple's libc shells out to Perl to implement wordexp

#16
post #9
post #5

As it's already written in the manual... http://linux.die.net/man/3/wordexp wordexp, wordfree - perform word expansion like a posix-shell So, the implementer decided to take the short route, and just spawn a shell which, essentially, gets passed the input data to wordexp(), to do the work. But, of course, having something that starts with such a comment... /* XXX this is _not_ designed to be fast (...) wordexp is als…

"Like a POSIX shell" includes expanding command substitution. wordexp("`echo hi`") should return {"hi", NULL}. So it isn't totally ridiculous to reach for a shell; tracking multiple subprocesses, and nested command substitution (like "$(echo $(echo $(echo foo) $(echo bar)))") is a pain to reimplement correctly. In an ideal world, we'd have a libsh that exposed all of the steps of what /bin/sh does in a nice fashion,…

I understand that spawning a shell to do the expansion work probably is a good idea when your goal is to "expand a string like the shell".

But my guess is that most users will call wordexp() just to expand a few variables or tilde-homedirs.

Re: Apple's libc shells out to Perl to implement wordexp

#17
post #6

This is source code from 2011. Checking http://opensource.apple.com will show that it's not longer implemented this way in 10.10. Here's the current implementation: http://opensource.apple.com/source/Libc/Libc-1044.1.2/gen/Fr...

The current one is a derivative of NetBSD's implementation (where it shells out to use a sh builtin)

Re: Apple's libc shells out to Perl to implement wordexp

#18
post #17
post #6

This is source code from 2011. Checking http://opensource.apple.com will show that it's not longer implemented this way in 10.10. Here's the current implementation: http://opensource.apple.com/source/Libc/Libc-1044.1.2/gen/Fr...

The current one is a derivative of NetBSD's implementation (where it shells out to use a sh builtin)

Judging by both the source code and its placement in the repository (gen/FreeBSD/wordexp.c), I'm thinking it's a derivative of the FreeBSD implementation (which may itself be a derivative of the NetBSD implementation, or perhaps the other way around).

Re: Apple's libc shells out to Perl to implement wordexp

#19
post #13
post #3

Well, you are warned: /* XXX this is _not_ designed to be fast */

Performance is the least of my worries here. I'd be more worried about security, and plain dependency management. I mean, let's say this libc thing is supposed to be installed in quite a lot of systems, are we really sure that perl thing is installed in all of those systems? And what if, by some crazy coincidence, perl happens to depend on libc?

In Debian, at least, there's actually a number of circular dependencies within the (small) set of packages marked as "essential"; they all sort of lean on one-another like a house of cards. Perl is in that set, if you're wondering.

Re: Apple's libc shells out to Perl to implement wordexp

#20
post #13
post #3

Well, you are warned: /* XXX this is _not_ designed to be fast */

Performance is the least of my worries here. I'd be more worried about security, and plain dependency management. I mean, let's say this libc thing is supposed to be installed in quite a lot of systems, are we really sure that perl thing is installed in all of those systems? And what if, by some crazy coincidence, perl happens to depend on libc?

Almost everything depends on perl. Unless you're running a very small embedded setup, you'll have extremely hard time living without perl.

Circular dependencies are perfectly normal.

Post reply on HN