3 ms·

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

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...

adamnemecek 12y ago
> 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)
- Intermernet 12y ago
  Thanks, much appreciated. I thought there may be some strange cyclic dependency going on, but it seems not.
  - ksherlock 12y ago
    It would only be a problem if that specific perl command (perl -e 'print join(chr(0), @ARGV), chr(0)' -- args....) or the shell invoking it depended on wordexp(). Recursion is fine as long as it terminates.
SrslyJosh 12y ago
> Inserting a NUL byte between each word, and at the end doesn't sound like it requires Perl... No, it's more clever than that. The shell will actually execute something like this: /usr/bin/perl -e 'print join(chr(0), @ARGV), chr(0)' -- your input string goes here So, what happens is that the shell (in this case, bash) performs argument expansion on your input string, then calls perl -e '...' with the expanded words as its arguments. What perl does is join all of those arguments with a NUL byte and spit them back out for the calling process to read, which makes figuring out where each expanded "word" begins and ends really simple. Could you do this in shell? Probably. Would a correct implementation be as short and easy to understand? Probably not. Therefore, perl.

3 ms·

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

by Intermernet 12y ago

adamnemecek 12y ago
> 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)
- Intermernet 12y ago
  Thanks, much appreciated. I thought there may be some strange cyclic dependency going on, but it seems not.
  - ksherlock 12y ago
    It would only be a problem if that specific perl command (perl -e 'print join(chr(0), @ARGV), chr(0)' -- args....) or the shell invoking it depended on wordexp(). Recursion is fine as long as it terminates.
SrslyJosh 12y ago
> Inserting a NUL byte between each word, and at the end doesn't sound like it requires Perl... No, it's more clever than that. The shell will actually execute something like this: /usr/bin/perl -e 'print join(chr(0), @ARGV), chr(0)' -- your input string goes here So, what happens is that the shell (in this case, bash) performs argument expansion on your input string, then calls perl -e '...' with the expanded words as its arguments. What perl does is join all of those arguments with a NUL byte and spit them back out for the calling process to read, which makes figuring out where each expanded "word" begins and ends really simple. Could you do this in shell? Probably. Would a correct implementation be as short and easy to understand? Probably not. Therefore, perl.