Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^4: Avoid headaches from Strawberry Perl 5.10.0 and binary SVK

by dragonchild (Archbishop)
on Jan 09, 2008 at 17:47 UTC ( [id://661430]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Avoid headaches from Strawberry Perl 5.10.0 and binary SVK
in thread Avoid headaches from Strawberry Perl 5.10.0 and binary SVK

Changes made by a command in Unix cannot affect the shell the command was invoked from. This is because all commands are run in child processes. Apparently, Windows runs things in child threads?

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re^4: Avoid headaches from Strawberry Perl 5.10.0 and binary SVK

Replies are listed 'Best First'.
Re^5: Avoid headaches from Strawberry Perl 5.10.0 and binary SVK
by BrowserUk (Patriarch) on Jan 09, 2008 at 17:57 UTC
    Apparently, Windows runs things in child threads?

    No. No threads involved either. When unix runs a shell script, it forks the existing shell and runs the script in the child process. And environment changes are made to the child's environment block and so disappear when that shell exits. Whilst it runs, the original shell sits in the background and waits. And it is to that parent shell instance that you are returned, when the script ends.

    In Windows, the .bat file is run within the same instance into which the command is entered and it is to that same instance that you are returned when the bat file ends. So any changes the .bat file makes to that shell instances environment are persisted.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Ah. Wow. Maybe I'm just brainwashed, but letting program changes persist just seems like a recipe for disaster. *shrugs*

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        letting program changes persist just seems like a recipe for disaster.

        Hm. Maybe I gave a false impression? They only persist, for that instance of the shell, and only until that shell instance terminates. And by that judgement, isn't the following also a potentially disasterous recipe?

        c:\test>perl -de1 Loading DB routines from perl5db.pl version 1.3 Editor support available. Enter h or `h h' for help, or `perldoc perldebug' for more help. main::(-e:1): 1 DB<1> $x = 12345 DB<2> print $x 12345 DB<3>

        Because replace DB<1> with c:\test> and it is exactly analogous. And in any case, the behaviour is easily altered to your preferred option:

        C:\test>path PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\T... C:\test>cmd /c "set path=a load of junk here && path" PATH=a load of junk here C:\test>path PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\T...

        Or when invoking a bat file you can avoid it changing the current shell instance by explicitly starting a new instance of the shell to run it as in:

        C:\test>type junk.bat set test=this is the value set inside the .bat file c:\test>start /b junk.bat c:\test>set test=this is the value set inside the .bat file c:\test>set test Environment variable test not defined

        So either behaviour is easily available. And here's yet another way to choose the required behaviour:

        c:\test>type junk.bat set test1=this persists setlocal set test2=this does not persist endlocal set test3=and this persists also c:\test>set | find "test" c:\test>junk c:\test>set test1=this persists c:\test>setlocal c:\test>set test2=this does not persist c:\test>endlocal c:\test>set test3=and this persists also c:\test>set | find "test" test1=this persists test3=and this persists also

        We could argue till we are blue in the face about which is the correct behaviour, but the reality is that these are two different systems with two different 'default' behaviours. So assuming that they are the same, or complaining that they are not is futile.

        I could also argue that the Win32 behaviour is more flexible because it gives you the choice, and that there are some very definite uses for it's default behaviour. But I'm guessing you probably won't read down this far, and they would fall on deaf ears even if you do.

        And that in a nutshell is my major problem with efforts like cygwin and Strawberry Perl.

        • cygwin, as effective as it is at doing what it sets out to do, is for all the word like fitting a set of handlbars to a family estate car and expecting it to handle like a motorbike.

          If you want a motorbike, buy one.

        • Strawberry Perl worries me exactly because it appears to have been successful in pursuading a number of key Perl contribtors to use it in preference to AS.

          Whilst I acknowledge that it has brought some benefits to Win32 users, it has set the precedent that it is becoming the defacto target for win32 development effort when most users live in the AS world. That makes for a world where many incompatibilities remain and some will not, by definition cannot, be addressed.

          It also means that by "dodging the bullet" of fixing the AS port, it removes the possibility for allowing Perl full access to some of the uniquely Win32 technologies that could really benefit Win32 Perl users.

        The attempt is to make win32 look and behave like *nix so that *nix people are more comfortable and can pretend that they do not sully themselves. But in that attempt, they create more problems than they resolve. And, by the by, throw away the potential for some really good stuff.

        Just as it is unlikely that I could ever get up to speed on *nix to rival the hardcore *nix Perl developers. It is, with rare exception, unreasonable to expect that many of them will get up to speed on win32 development sufficiently to exploit the full potential of Perl on Win32. The only solution I see is for pairs of people to get together from both sides to drive things forward to successfully exploit the potential from both sides. But that requires feedback.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://661430]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (7)
As of 2024-05-21 00:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found