At Wed, 8 Nov 2017 10:55:13 -0800, Matthew Butterick wrote: > > > On Nov 8, 2017, at 9:17 AM, Matthew Flatt <[email protected]> wrote: > > > > DrRacket tries not to interfere with programs in a detectable way. > > Hmm ... so if DrRacket adopts a different set of environment variables from > command-line `racket` — which I assume is the correct and just policy — isn't > that naturally going to lead to detectable differences, for a program that > depends on those variables?
As others have said, both `racket` and `DrRacket` just accept the environment variables that the environment gives them, and Finder and bash set up different environments. > > Is there something more general that you want to test for DrRacket --- > > some effect on the execution environment that might be due to DrRacket > > or some other tool/configuration? If so, it could make sense to set up > > some way of communicating that to a program. > > In this case I was trying to configure a web servlet to run in differently > when launched from DrRacket (in terms of its port and servlet-path) to better > approximate Apache / htaccess conditions that exist on the live web server. I wonder whether a submodule is a better approach here. DrRacket implicitly runs a `test` submodule, while `racket` doesn't, and you could add more submodules to the list in DrRacket. But that approach doesn't work if the conditional adjustment goes in a library, instead of the main module. Maybe DrRacket should let you configure environment variables for a program in the same way that it lets you provide command-line arguments, and maybe it does make sense to have a default environment variable that means "running in development mode". -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
