Environment Variables and Path in Windows 10
plus.google.com
plus.google.com
(1) It's self-contained piece of UI code. It's not like this change will permeate effects throughout the OS.
(2) It's a few man days of work. Let's say that as a super-exaggerated-extreme estimate, it is still only a few months of work.
(3) Nobody was dependent on the current behavior.
(4) Everybody hated the current behavior. Programmers jumped through hoops like copying&pasting the strings into an editor, making a change, and pasting it back.
(5) They had at least 23 years to fix it (since at least Windows 3.1).
There are more plausible explanations about MH370 than there are about Microsoft's thinking here.
https://msdn.microsoft.com/en-us/library/windows/desktop/ee8...
> We recommend registering your application in the App Paths registry subkey. Doing so avoids the need for applications to modify the system PATH environment variable.
http://blogs.msdn.com/b/oldnewthing/archive/2011/07/25/10189...
> On top of the difficulty of adding more directories to the PATH, there was the recognition that this was another case of using a global setting to solve a local problem. It seemed wasteful to add a directory to the path just so you could find one file. Each additional directory on the path slowed down path sarching operations, even the ones unrelated to locating that one program.
> Enter App Paths. The idea here is that instead of adding your application directory to the path, you just create an entry under the App Paths key saying, "If somebody is looking to execute contoso.exe, I put it over here." Instead of adding an entire directory to the path, you just add a single file, and it's used only for application execution purposes, so it doesn't slow down other path search operations like loading DLLs.
Like... in Windows motherfucking NINETY-FIVE you could edit your PATH variable without having to restart, why do I have to log out and back in in 2015 for Linux to accept those changes. Why do I have to mess around with random scripts that may or may not be executed by one of the many steps launching my session. What is this madness.
<waves hand> There is no problem with editing environment variables in Linux.
<waves hand> You're going to go back to your terminal and re-think how you use environment variables.
Seriously, nobody has this problem on Linux desktops because folks usually--if they're going to mess with environment variables at all--they're going to do it right after getting a new home directory (i.e. a new desktop where logging out and back in one time isn't a concern) or they're going to set them in a script of some sort. As in, start_server.sh or, "oh fuck this I'll just write a small shell script that sets PATH and launches what I want" which is perfectly normal and reasonable; if your application needs certain environment variables set to function properly why would you want to leave such things to chance? Just set it in the script that launches your app.
Unlike Windows, a Linux desktop has no mandatory distinction between a shell script and a binary in order for it to be executed. If it's set as executable it's executable; simple as that. The user probably won't know or care that /usr/bin/yourapp is really a shell script that sets up some environment variables before launching /opt/you/bin/youractualapp
Not only that but you don't have to log out and log back in--that's just the cop-out, "I'm lazy" way of applying such changes to your desktop. You could just restart your launcher. I use KDE's Plasma desktop so that would be:
killall plasmashell kstart plasmashell
If you're SSH'd into your Linux box it's even easier: . ~/.bashrc
Windows gets over this problem by letting the login shell (explorer.exe) reload the environment variables in place. So, if we are to do the same thing in Linux, we might have to patch bash, zsh, and GNOME etc. to understand the environment variable change events and reload itself appropriately. I'm not sure where to start, but I believe this is the one thing that Windows did right, so I want to see it happen.
. ~/.profile
As someone else mentioned down below, if you just need a new login shell with your variable changes just do this:
exec /bin/bash -l
Also a tip if you're using KDE: You don't need to logout and back in. Just do this:
killall plasmashell
kstart plasmashell
So, the OS tells everyone 'Hey, you totally could update your environment'. But your running instance of Skype or whatever just doesn't need to care.
$ /bin/bash -l
Fix that by running:
$ exec /bin/bash -l
1) Click desktop icon to launch shell
2) /opt/myfirstgui/run.sh & disown
3) Close shellThis drives me nuts on Linux: env. vars aren't systemically available as on Windows where you even have an option to broadcast change so that even running applications can update. I wonder why there isn't POSIX standard for this, perhaps /etc/environment would be good choice if standardized.
On Windows, you don't really need any than that. To get PATH env var the way it is now in Win 10 just do in any windows
PS> $Env:Path -split ';'
So please Windows admins, stop being fucking clickzor n00bs and start using Powershell. Its embarrassing.
As a related note, the most awesome of all editors on Windows is Total Commander "Environment Variables" plugin - you can do all kinds of stuff there (regex search/replace, backup/restore as simple file copy, fuzzy search, bookmarks ..)
PS> $Env:Path - split ';'
I mean, yeah, sure, it can happen once in a lifetime... Even so, its easy to fix.
If you want a new environment variable added, or one altered, it needs to be sent out to the UI process that starts new tasks (like shells, applications and so on). To be extra clever, this new environment message could also be passed to running terminal emulators as well (so that if you open a new tab in a running app, the shell started in there will also obtain the new variables)
Environment change to send (something) to UI process(es). Plural here -- these could be window manager, shell, or applications. Since application subsumes window manager and shell, we will ignore that. Unless the application is forced to say "I am interested" to (say) systemd. Or dbus.
Then, accept the environment changes. But, those will have to be filtered -- this could be user input. Indeed, the application may have an application starter, and one the jobs of the application starter may be to filter the environment. The application starter may never expect an environment change, but the application started may (in our "new world" API). This could result in security holes (especially for large daemon processes). Interestingly, the main purpose of this change would be to allow the environment to change dynamically for those daemons.
The "extra clever" is the easy case -- make changes in .bashrc This will get read by new tabs in your terminal emulator.
Having an application starter that is responsible for the environment is the (current) solution. Of course, this does not permit environment changes. But these are impossible anyway -- int main(int ac, char av, char envp) implies that the environment passed to main must not be altered. Of course SUSv3 doesn't specify it, and getenv() putenv() should be used. Hoever, extern char environ; is allowed, which is the same as char envp.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/en...
http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...
So, an application can do char path = getenv("PATH"); to obtain the PATH. After which, char path will not change (as long as getenv(), setenv, unsetenv() or putenv() is not called, and environ is not written).
Which means that it is very difficult to "inject" a PATH change -- it should be impossible. Another mechanism must be put into place for this, but POSIX semantics should be maintained.
In my code, I tend to do strdup(getenv("PATH")) or something along those lines (note that getenv() may invalidate a previous getenv() so it is not safe to store the result char* of getenv()).
Ratboy
To restart popular desktops/launchers without logging out:
KDE
killall plasmashell
kstart plasmashell
killall -3 gnome-shell
unity --replace &> /dev/null & disown
killall -HUP xfdesktopI've always programmed primarily on UNIX like platforms but one thing that I've realized is that Windows provides a really powerful and stable API which makes tools like this possible. Microsoft likes to provide APIs and let developers build stuff like this.
This indicates to me that you've never worked in a software company like Microsoft. EVERYTHING that Microsoft does is under a huge amount of scrutiny, and any change to anything generally will piss someone off. So they are careful with every change and they have to be thorough.
It's not just a few months worth of work. Sure, the development change of the UI could be done in a couple of days. But the design first has to be hammered out and agreed to. It has to agree with how the rest of the system would behave. Not to say that this dialog box was in agreement with the rest of the dialog boxes from XP to Windows 8, but if they're going to change it now, then whoever makes the change would need to make sure their version does. This would take man-weeks of meetings just to get right from the PM and designers, etc.
But then there are QA changes that need to be done, just to test it, so add on a couple of weeks for that. It would presumably break all of their automated testing, and then new tests would have to be created. Ballpark figure just for that is 4 man-weeks of QA work.
Then, are there any dependencies on the older version of the UI to other products? Not sure, probably not but it would have to be researched.
What about documentation changes? Not only will the Windows documentation need to change, but then all other software that references adding environment variables need to change. And now, training videos will have to be changed. Don't forget that Microsoft has a bunch of training classes that they offer.
Will enterprise customers be impacted by this? Not sure, but they would probably want to reach out to their most important ones to figure out what
Now, take all the time estimates and then figure out how this compares to other bugs that have been lingering for years as well. Is the current functionality unusable, or is it just kind of sucky. If it's just kind of sucky but people can live with it, then time is probably better spent on other things.
Do this about 6 times on the most widely used piece of software in the world, and you have yourself 20+ years.
Should this dialog have been changed years ago? Yes, it sucks, and almost embarrassing. But it's still usable, so it has relatively low priority. This is how software decisions are generally made in enterprise software companies, especially those like Microsoft.
Windows 8 was the result of feature prioritization based on incorrect/skewed customer intelligence. Management knew what they wanted and skewed the market research to validate their position. Dev/test/pm then set to work validating and polishing the wrong features.
My guess what has changed is with the death of the SDET role that Windows feature planning is no longer test-constrained (for better or worse) and thus can greenlight features such as this.
But before you say 'I can get that done in 2 days'- take into account automated testing, localization, accessibility testing, security review, documentation, etc.
Can you give some more details? This bit sounds strange.
That is an interesting statement. The reason why this little piece of work (similiar a resizable cmd window) hasn't been done before shows the fundamental differences between Linux and Windows in what the creators think it was made for. 99 % of the Windows users will never use the env var dialog. Microsoft gave the other 1 % (devs) Microsoft obviously a very low priority in the past.
That has changed. While I like Windows 10 overall, I still wish it was not so chatty. I don't want to need to think about what kind of personal information my devices steal and how to protect myself. I don't like it from my Android phone and I don't like it from my laptop.
You know there's a lot of bad things to say about Microsoft (I still can't get other the "telemetry updates" and I'm seriously studying moving to Ubuntu 15.10) but saying MS gave developers a very low priority is probably the mots unjust criticism you could ever give them and tells me you probably never developed anything on Windows.
I'd go even as far as to say that MS is the most developer friendly corp out there. The amount of effort they put in their tools, languages, frameworks, whatever is impressive. It's easy and it just works.
Microsoft is to devs what Apple is to users.
A couple of people have referred to this, but I've been resizing CMD windows for over a decade. Maybe you mean you couldn't increase the width by dragging, only via a dialog?
[0] http://i.imgur.com/GAbg5TR.png
Edited to add: This is Windows 7, 64-bit.
It's rather inconvenient, though.
I've seen simple problems like this one that have taken forever to fix in big orgs where task prioritization was done at such a high level that anything that can't be called a bug, or considered very high impact, is ever even evaluated seriously as a candidate for change.
When teams have more agency on what they change, then an enterprising developer that realizes how annoying the 'not quite a bug' is, and how easy it is to fix, can just be proactive, put it high in his team backlog, and get it done.
At my current employer, we don't quite do old Google style 20% time, but we let developers ignore the sprint goals one day a week, as long as they are doing something that aims to help their team and their high level goals. How many people actually use that opportunity is a good measurement of how much teams believe in the planning that is being done: When a team's highlights for a given quarter all come from those unplanned features, that means that the direction the team was given made no sense, and we have to figure out why.
Explaining this well is really difficult, so I hope you don't mind me resorting to a metaphor. Imagine you are the chef of a restaurant and you work alone with your one waiter. You run the kitchen and they deal with the customers.
Quite a lot of your work will be directly related to customer orders. You need to set the menu and go shopping and prep all the food. In addition to that, there are also some things that you need to do all the time like sharpen your knife, disinfect your cutting board, etc, etc. You could prep more food if you didn't have to do those things, but if you don't do them, then things will be quite a bit slower, so you have to budget some time for that. Still, these are things that you can do when customers aren't in the restaurant, so it's easy to budget.
Once the customers come, you have to react to their orders. However, that's not all you have to do. You also have to clean your pans, wipe your board, keep your knife clean, shuffle food between your fridge, your board, your pans, etc. You also have to do extra prep work for things that you estimated wrong at the beginning of the day, or for special orders that come in.
You could just pile up dirty pans as you go, but eventually you will have nothing to cook with. You have to find time to clean them as you go. You could take everything out of the fridge and leave it on your board, but then you won't have room to prepare the food and your food will spoil.
Prioritising this work is not something that can be done in a meeting. The chef doesn't stop and chat with the waiter about whose food has the highest priority and negotiate, "Maybe wash that pan later, so that we can serve this dish first. We'll take the hit of unsatisfied customers who have to wait and watch you wash dishes for half an hour later." The judgement call is left up to the chef because it is the chef who knows better than anyone how to keep a constant throughput in order to keep the customers happy.
It doesn't mean that the waiter has no say in the matter. If they perceive that something needs fixing now, they must say it, but the chef needs to figure out how to accomplish that while keeping the kitchen moving.
In our software shops, we tend to listen to our stakeholders and given them literally what they are asking for. We often don't make the judgement call correctly of how to keep the "kitchen" moving. Our project managers often press the big red panic button and say, "Stop everything and just fry the steak. Don't wash dishes. Don't put the meat back in the firdge. Don't clean the board. Don't clean your knife. Don't prep for the next customer." -- with predictable results.
Adding a 20% (or whatever) "budget" for allowing the developer to choose what to do is great, but the reality is that the developer needs to be able to choose what to do next 100% of the time -- and they need to have the ability and experience to choose correctly most of that 100%. This is the tricky part. If you do not have people like that on your staff, then you may be stuck trying to get by with planned work. It's going to be a crappy kitchen: food left out to waste, knives unsharped, dishes piling up in the sink. You might be fortunate enough to have someone on your team who will choose to wash they mountains of dishes in their "20% time", but the odds are fairly slim. What you really need is a chef who can direct traffic in the kitchen and who has the authority to make judgement calls 100% of the time.
Note: If you ever get a chance to watch on open kitchen with a single chef who does everything, it is a fascinating experience. Only a small fraction of their time is spent actually cooking your food. Most of it is shuffling things around, cleaning and organizing. Yes, most professional kitchens have specialized positions, but I think this is metaphor is closer to the reality of programmers.
The DOS prompt being terrible for 20 years might have similar justification. In 1995 MS would have many developers who would have just shifted their DOS apps to the command line if they could have gotten away with it.
The OSX finder may have been made similar ideas in mind.
I don't think it's inexplicable at all. "It wasn't considered to be an important enough change to be worth developer time by the people who owned that chunk of the codebase." Maybe it became important enough, or maybe somebody decided to make it their priority to push the change through, but random sharp edges show up in enterprise products, and persist, all the time.
26 drive letters? The NT kernel and NTFS/ReFS are very flexible, just update the WinAPI!
For some reason MS nowadays messes around with the UI (Win8/10 theming isn't that beautiful nor intuitive), the privacy settings, windows update, instead of keeping the Win9x/XP/Vista themes and improving the Win32 subsystem. Even WinRuntime API is a Win32 subsystem citizen. Either improve it or port WinRT to another subsystem. I wonder what Dave Cutler is working on at the moment (after VMS, WinNT kernel, XBox and Azure platform), or has he retired?
I wish Microsoft would just put their support behind one of the popular open-source filesystems and release it as an alternative filesystem for Windows. This plus an officially supported NFS server and a POSIX compatible API would dramatically increase the viability of using Windows natively for development.
NTFS is case sensitive.
NTFS does not have a 260ch path limit.
The slowness of stat() (or at least part of it) is due to the inefficient way Win32 does filesystem enumeration/status queries.
Also, upper/lowercasing is not defined the same in all languages. In turkish, i becomes uppercase Í.
Press CTRL-F (find/replace), and you'll note that even in Excel 2013 CTRL-A (select all) doesn't work in either the find or replace boxes.
It has been this way since at least Office 95.
Imagine you'll be able access this through the online help:
https://support.office.com/en-us/article/Excel-functions-by-...
The offline help is fine for Excel functions. But where I work, 90% of the functions used are coming from addins, and even though they also have a documentation somewhere, it can't be reached with F1.
Documentation is necessary but hints should be inline/contextual, like intellisense in visual studio. I don't want to have to leave what I am doing just to figure out which is the next argument in a function.
Excel could use a powerful autocomplete like intellisense that gives you basic documentation inside the auto-complete.
But Office is the "sleeping beauty" of Microsoft. A bit of an old and hairy beauty though.
Nothing made it harder to get people to use Java apps then telling them to download and install a runtime and then add some path things to some mercurial and hard to use part of the OS.
Just about the only time I've ever had to interact with the path dialog on a windows system its been for the purpose of setting up java.
And sun/oracle hasn't done any favors for themselves either in making the setup process better.
Massive understatement! :)
As well, in my limited experience, vendors who write something java-based absolutely can't be bothered to write a help document on how to configure java to run their app despite hundreds of people posting in forums asking for help...."not our problem, you should know how to do that" seems to be the sentiment.
Also, 3rd party software can provide that functionality
At least, it did get revamped.
Notepad and the Command window are still pretty much what they were in Windows 95.
I was almost shocked when I discovered that one. I had honestly given up thinking it would never get fixed.
1.) Don't set the filter on the file open dialog as .txt, by default, just make it all files.
2.) Handle newlines properly, even if they are evil Mac or Linux style ones.
For the love of Cthulhu, don't rewrite it as a Modern app, just fix a few of the things that have been irritating for twenty years.
I'm honestly curious about this remark.
If Modern apps today were as limited as they were in Windows 8 then I'd wholeheartedly agree with you. But I actually find Modern apps in Windows 10 to be quite usable now that they can be freely resized and managed like any regular application.
I personally use several modern apps on a day to day basis, namely Mail, Calendar, Finance, Reader, Calculator, and the Office apps (in place of the full suite that I no longer have installed, saving several Gigabytes on my SSD), and I really struggle to think of any glaring issues that would make someone so vehemently condemn this entire class of apps.
For example with Groove Music and Movie player, I can't drag and drop a folder with music or videos to them to add to a playlist. To me this is a step backwards.
Other than that I do believe they improved a lot since windows 8 and they are much more functional.
[1]: https://msdn.microsoft.com/en-us/library/windows/apps/mt2276...
I also remember reading somewhere that the problem exists only when drag and drop is done between modern apps and win32 apps.
But Notepad has so few features that there'd probably be no benefit.
ReactOS's version of notepad handles this properly. Grab the ReactOS livecd (63.9MB zipped) and copy notepad.exe off it. :)
Of course, by the time you've gotten to that point, you've probably installed a better editor.
[1] http://docs.asp.net/en/latest/fundamentals/configuration.htm...
And server admins/devops won't have a problem. Applications will hopefully use variable with a prefix, e.g. App123Debug
Hopefully...
What people want:
A static class that sets itself up on its own
What they've given everyone:
A class you've got to inject and instantiate on your own using IOptions<TOption> with each call to Configure<TOption> adding an IConfigureOptions<TOption> service to the service container that is used by the IOptions<TOption>
Mind boggles at the over-engineering.
They're just being consistent with the way most software is written nowadays.
.profile is a login script, not the recommended place for setting variables although historically it has been because /etc/environment and ~/.pam_environment are relatively recent additions to Linux. (Why didn't distros adopt the ~/.env though that other Unixes, like AIX, use?) But there Windows also has the profile login script and I don't know if it's possible to export environment variables from it but that serves the same purpose of ~/.profile.
So all those things you say are bad about Linux exist on Windows.
So the question you're asking is a bit moot, in a way, considering that the answer is yes, because that's exactly the way it is. It cannot be any other way, as far as I can see.
Maybe the rest of the dialog controls are all fixed dimensions and non-autosizable.
Still, that seems like the kind of thing you could unleash a platoon of interns on and modernize, though.
That's exactly the problem. Raw Win32 doesn't really have provisions for layouting containers and auto-resize behaviour. So you'd essentially have to handle WM_SIZE and reposition/resize all controls in the dialog. Such code is cumbersome to write, awkward to change and annoying to debug/test (e.g. you still need to check that you don't change something to negative sizes and/or constrain the window dimensions appropriately). And in the end you have a few hundred lines of code that are intricately linked to the current dialog layout and, in part, even replicate the layout. So you cannot even easily change the layout anymore. This is quite a bit of a cost associated with that.
Inventing layout containers on the Win32 side seems a pointless idea as well, considering that nearly no one except Microsoft actually uses the API at that level, so improvements here have little benefit for lots of work. Most people most likely use wrappers around it that offer such things (e.g. Windows Forms), or things that take care of their own rendering and offer layout containers (WPF, Swing, GTK, Qt, ...).
So I guess if MS offered the usual layout mechanisms in Win32 people would just shrug and ask »Why? I already have those things in the toolkit I use. Can't they devote development resources to actually important things?«.
[1] "One of the top requested changes we’ve received over the years is to have quick-edit mode enabled by default. Tada!"
[2] http://blogs.msdn.com/b/oldnewthing/archive/2007/09/13/48861...
Like an hour instead of few minutes.
I remember also, that coworkers had the same issue. One of them left work once, leaving a long process running. He came back the next day and it hadn't finish yet. He was ready to file a bug report somewhere, when we found out...
If you click on the command prompt with the QuickEdit mode turned on, in a "wrong way", the underlying process will be frozen. It's because the input and output streams are blocked indefinitely, until you finish your selection and the content gets copied to the clipboard.
So, why would you want to click on it? There is a common pattern people use for long running scripts: they push the window somewhere in the background, but leave a little space you can click on, so that you can view it very quickly.
The "wrong way" of clicking is when you do click-drag instead of a point click. It goes automatically into the QuickEdit mode freezing everything underneath it.
Also, seriously, is there a way to get the console to reliably remember the size and layout settings between launches? At least half the time I launch something with a console window, it's smashed into a 80x25 window, with the ridiculously low 300 line scroll history.
For the command window size and scrollback buffer, I've always had good luck - in Windows 10 and older versions - by setting the options in the Layout tab of the command prompt property pages. I also use the Font tab to select Consolas.
It is true that some programs that open their own command window don't follow these settings, but I usually open cmd.exe and go from there.
For window size that's been easy to fix since forever. Just click the upper left corner icon and select either properties or defaults. Properties changes the settings for the shortcut if it was launched from one, defaults changes the settings for all cmd windows. In addition to window size and selection mode you can change the font and colors and whatnot.
That's more a problem with those programs than anything about the length of an environment variable.
Just a couple days ago, I tried to add a tool to my PATH and it wouldn't stick because both Intel and Microsoft decided that their utility needed not only both Program Files and Program Files (x86) for each (doubling their PATH usage), but Intel also decided to arbitrarily use positively uselessly long directory names. As in, I actually think it's plausible Intel specifically did it to screw over PATH usage.
Infuriatingly, the hard PATH limit is after any environment variables have been expanded, meaning there's no reasonable way to compress the path down. (Never mind that it also only expands variables less than the string 'PATH'.) In the end, I used DIR to find what the 8dot3 representation of each repeated or long directory was.
Now I have enough free characters, but no fracking idea exactly where they point. It's the sort of crazy that I really thought would have been lic'd by now.
Edit: I forgot to note that the hard limit is a truncation. So while you can happily add to the PATH variable in the (now out-dated) dialog, the actual console won't see all of it. I had moved folders around before my rant above such that my final PATH exactly ended on "\node\bin". It's sort of a weird game of PATH golf at this point for me.
I just remove the Intel folders from my PATH (every time one of their drivers resmashes them into the PATH).
[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/07/25/10189...
became
http://cloud.addictivetips.com/wp-content/uploads/2012/03/wi...
a few years ago. Although I think it's for the worse, it hasn't stayed the same since 1998.
Edit: I think I fat finger downvoted parent, sorry
Maybe someday we will have a decent terminal window, too!
Have you checked lately? ;)
launchctl setenv MYVAR myval
That said, OS X is fairly hostile to the use of environment variables as required settings for GUI apps. Personally, I can't really blame them...
Edit: Don't know if you know this, but you can use "launchctl setenv key value" to set environment variables that get used by GUI programs. Unfortunately there are 2 huge caveats: 1) it's not persistent so you need to make something that load them at boot time, and 2) if you load them too late, they won't be part of the Dock or Finder process and you'll need to restart those processes to get your custom env vars in there. When you click something from the Dock, it inherits the environment from the Dock, so it's important to get your vars into the Dock itself.
I've now grown used to running a script manually at boot time and then doing "killall Dock" so that when I launch Emacs or XCode I get the right PATH. If someone has a smoother solution, I'd love to hear it.
You can use 'setx' to permanently set envars too.
You don't need to logout to use them, just restart cmd or whatever program you use.
Get-ChildItem env:
New-Item -Path "env:\myvar" -Value "MyValue"
Amongst other things, it works for the registry and even Active Directory.
Edit: for persistency you actually need to use [Environment]::SetEnvironmentVariable("TestVariable", "Test value.", "User")
# Save environment
$savedState = Get-ChildItem Env:
# Restore environment
Remove-Item Env:*
$savedState | ForEach-Object { Set-Content Env:$($_.Name) $_.Value }Are there OSs out there that address this solution in a less archaic way?
Path is a bit different because it's helpful being global so any command prompt can use it. Though the start menu search bar doesn't seem to so wouldn't it be better moved to a setting in the command prompt and Powershell applications themselves?
On the other hand, it was probably by design. Microsoft wanted to promote the Windows Registry and GUI of Win95/NT4 and made the command prompt (cmd.exe and other Unix/DOS alike parts) unpopular and not easy to use.
In terms of developer UX, i now have to do 1 step more (click add button, paste the string, click ok, click ok).
PS. It was rare that i actually had to change a path