in reply to [OT] Windows cmd.exe shell

Works fine ... but there must be something better ?

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

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

Replies are listed 'Best First'.
Re^2: [OT] Windows cmd.exe shell (perl.exe)
by bliako (Abbot) on Aug 01, 2019 at 18:49 UTC
Re^2: [OT] Windows cmd.exe shell (perl.exe)
by syphilis (Archbishop) on Aug 02, 2019 at 00:52 UTC
    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
      LOL

      perl -MConfig -MExtUtils::Embed -e " system $Config{cc}, qw/ -o interp interp.c /, ccopts(), ldopts() ; "

        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