Comment by cnvogel | Hacker News Reader

Comment by cnvogel | Hacker News Reader

Parent Full thread

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 also rife with security "challenges", unless you pass it WRDE_NOCMD it must support subshell expansion, and even if you don't beause it has to support so much of the standard shell (all the odd little variable expansion options for example) it is hard to do without a subshell). It is probably just plan a Bad Idea to call in anything setuid, or executing remotely. */

...in your standard C library wasn't such a smart idea to start with. Scroll down, there are many more gems in the comments!

Sometimes it's better to just implement it as

        void wordexp() {
                fprintf(stderr,"wordexp() is a security nightmare. Not implemented.\n");
                assert(0);
        }

or decide to deliberately only implement a safe subset of the full functionality specified (e.g. only ~user-homedir expansion and $VARIABLES), to at least cover the common use-cases without creating a security nightmare.

(EDIT: typos)

"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, this function would call one of the libsh functions, and /bin/sh would be a 10-line while (true) { libsh_this(); libsh_that(); }.

In a slightly less ideal world, the shell would have a way to separate things with null characters, without bothering Perl.

We really don't live in an ideal world.

> In an ideal world, we'd have a libsh that exposed all of the steps of what /bin/sh does in a nice fashion, this function would call one of the libsh functions, and /bin/sh would be a 10-line while (true) { libsh_this(); libsh_that(); }.

THIS, GODDAMNIT, THIS.

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.

The standard itself at http://pubs.opengroup.org/onlinepubs/9699919799/functions/wo... says "While wordexp() could be implemented entirely as a library routine, it is expected that most implementations run a shell in a subprocess to do the expansion" and gives guidance on how to implement it that way.

Is wordexp() a requiement for being POSIX compatible?

I searched through the FreeBSD repo on Gitbub and the only references to wordexp is basically the code itself. Searching the whole Github does not show many things either.

How common is the function in practice and how important is it?

requirement? yes. http://pubs.opengroup.org/onlinepubs/9699919799/functions/wo...

common in practice? openbsd doesn't support it. afaik few programs use it, and those that do are usually easily patched not to (can use glob instead or disable whatever feature entirely).

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

ESR hasn't been a role model for anything related to programming since, like, 1998.

"...and what a spelling errors...ESR writes about sloppy spelling..."

:-\

Reply on news.ycombinator.com