Re^2: [OT] Windows cmd.exe shell (perl.exe)

Yup, perl.exe is better, its like you're using it already :)

Yes - I don't think I've ever been faced with a task that is best solved by embedding perl in C code.
But even if embedding perl in C is unnecessary and/or perverse (and I'm not saying that it's always at least one of those), I still find it to be an interesting feature in its own right.
In fact, I find it so interesting that once every couple of years I'll spend an hour or two fiddling with it ;-)

Cheers,
Rob

Comment on Re^2: [OT] Windows cmd.exe shell (perl.exe)

Replies are listed 'Best First'.
Re^3: [OT] Windows cmd.exe shell (perl.exe) by Anonymous Monk on Aug 02, 2019 at 02:09 UTC
LOL `perl -MConfig -MExtUtils::Embed -e " system $Config{cc}, qw/ -o interp interp.c /, ccopts(), ldopts() ; "`	[reply] [d/l]
Re^4: [OT] Windows cmd.exe shell (perl.exe) by syphilis (Archbishop) on Aug 02, 2019 at 05:12 UTC
perl -MConfig -MExtUtils::Embed -e " system $Config{cc}, qw/ -o interp interp.c /, ccopts(), ldopts() ; " There's probably a fairly straightforward perl one liner to do the job - but the quoted one liner is not it. The problem is that ccopts() and ldopts() don't return the values we're seeking - instead they print those values to STDOUT (or STDERR, FAIK ... I haven't checked). So we first need to capture those outputs before we can pass them to the system call. In the script that I hacked up, I discovered that I needed to chomp() the ldopts() output, though not the ccopts() output. That seemed a bit odd, but rather than try to work out what was going on I just decided to chomp() both outputs for safety. Cheers, Rob	[reply]