What's completely inexplicable is why it took 23 years to do this.
Consider this:
(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.
> 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.
> 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.
What's even more inexplicable is that you can't do the same on Linux. For all the developer-friendliness of the platform, nothing infuriates me more than having to edit my PATH/LD_LIBRARY_PATH/etc. by editing my .bashrc and then having to log out and back in again. Not to mention that programs you start from the GUI launcher don't source that file so if you need a program to start with one of them set, you actually need to edit .profile... wait no that doesn't work, I mean /etc/profile.d/99-my-path.conf... no actually it's /etc/environment... or is it /etc/profile... oh fuck this I'll just write a small shell script that sets PATH and launches what I want.
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
If you place environment variables in ~/.bashrc, it would work. However, generally they are placed in ~/.profile which is read only when a login shell is launched. (And ~/.bashrc is not even read when you start a GUI session, anyways.) This is especially problematic in the GUI environment because in that case the login shell is the desktop environment itself. So you need to restart the whole environment (close all the windows, logout, and login) to load the new environment variables.
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.
If you made a change to your .profile why wouldn't you just apply it?
. ~/.profile
Why logout and back in? You know which file was changed because you made the change.
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
(the -l meaning, "act as if... invoked as a login shell")
Also a tip if you're using KDE: You don't need to logout and back in. Just do this:
killall plasmashell
kstart plasmashell
That should apply any changes you've made to environment variables to any applications that get launched (subsequently) via KDE's usual methods (e.g. K menu or krunnner aka Alt-F2). Your running applications will remain open!
Changing how the environment works isn't a trivial change, it would have far-reaching consequences, and every program that reads the environment would need to be patched, not only the shells and display managers.
If the aim is to replicate how Windows works, only the GUI shell would need to reload environment variables (i.e. the process that forks when you start programs using whatever the desktop's idiom is).
This seems inconsistent behaviour to me. Some running processes reload the environment and others don't. Maybe in Windows they can get away with it, but that doesn't mean it's a good idea.
To be fair: The Windows way is kinda consistent: If the environment definition was changed, everyone gets a window message. It's just that no one but explorer.exe cares about that and reacts, as far as I'm aware (Raymond Chen had a recent article mentioning exactly this).
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.
Meh... GUI sux for this anyway, Windows is ahead of this generally then other Linux like OSes.
This 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 ';'
Setting the var in the system is equally fast and you can make stuff even better - for instance my POSH function keeps backup of old env var value, i.e. if i change the PATH today I would also have PATH_2015_10_26 with old value.
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 ..)
It can be confusing but it isn't that complicated. Basically you have to options, either let pam set the environment or use your shell of choice (in which case the shell start-up file should be sourced from the X session script as well). Having to log out and back in may be inconvenient but it's unavoidable and a small price to pay in my opinion.
It's not unavoidable / impossible. We (can) have the technology!
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.
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()).
And then when I click on my IDE icon on my desktop it will launch with the new PATH? It won't. That was a rhetorical question. You can tell by the way it stipulates a modicum of usability out of desktrap loonix.
Meh. I've been using Rapid Environment Editor[1] which is a free tool that allows editing environment variables on Windows and has a similar interface for editing PATH.
I'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.
One of the things Microsoft has done over the years is filling all those little holes that needed an extra download, setting up a new Windows machine no longer involves downloading a hundred tiny utilities.
>(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.
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 puts up a strong argument that at least some of the time features just get railroaded without all of that stuff. Anyway, i doubt google is as careful with android. If MS wants to reclaim the mobile space, which they had but lost due to being too slow, they need to move a lot faster, even if it sometimes breaks things. At the old rate of change, they'll end up losing the desktop to google as well.
Incorrect- Windows 8 had just as much dev/test/pm overhead for the features- Sinofsky was all about process (and triads).
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.
>> What's completely inexplicable is why it took 23 years to do this.
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.
"Microsoft gave the other 1 % (devs) Microsoft obviously a very low priority in the past."
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.
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?
When I try to maximise the the Cmd window, this[0] is the best that is achievable without custom apps. This is regardless of using either the horizontal resize handles or the Window Size properties.
I have no specific knowledge about how this was done, but it seems likely that the new way Windows development is organized led to a change like this happening.
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.
Pretty much this. A lot of startup and small business devs here are used to just being able to change software at their discretion which is awesome and great, but it just doesn't work that way often at enterprise shops. Changes and requirements come through the product management pipeline via customer interaction. Anything that isn't delivering business value in the form of appeasing existing customers (bug fixes and niche feature requests) or attracting new business (new features or integrations) is basically put into a backlog and forgotten until someone gets frustrated enough to sacrifice a weekend adding/fixing the backlog item.
We do a similar thing on my current team with respect to having a day to work on things that we think are important but aren't necessarily on the backlog. It seems to work reasonably well for this team, but there are some downsides.
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.
Perhaps it was because MS didn't want manual PATH alterations to be easy or they suspected too many people would have made their program only work if there was a manual alteration to it.
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.
> What's completely inexplicable is why it took 23 years to do this.
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.
MAXPATH limit? WinAPI/dotNetFramework only supports 260 chars in the file path. And the UNC path (no limitation) isn't supported even in Explorer and most APIs. NodeJS and cross platform devs would beg to improve it (the guys who wrote the Win32 API and made their life too easy by copying too much of the Win16 API)!
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?
The 260 chars file path limit is a huge pain point for me personally, since I do most of my development in a Vagrant Ubuntu VM for the portability and superior tooling support.
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.
I am not sure case sensitivity is a good thing. Do you really want users to wonder what is the difference between toolxyz.exe and Toolxyz.exe? How do they even google that?
Talking about a massively used piece of UI that Microsoft never updated in 20 years: the FX button near the formula bar in Excel. This is the only way to find a function with a description of what it does or to find what are the arguments of a function. It still shows a tiny non resizable window, with a list of thousands native functions and udf crammed in a tiny listbox, a search box that doesn't search anything, etc...
F1 is actually my worse enemy, too close to F2 for my fat fingers.
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.
Rarely does F1 work (like it used to) in most any MS app I've used in the last 5 years. I think they decided to just say fuck it and outsource that functionality to Google.
F1 works incredibly well in Visual Studio, especially if you're working with one of the flagship .NET languages. For example, highlight a core language element in your code, press F1 and you'll get specific help on it.
Putting on my conspiracy theory hat for a second, I bet this had to do with killing Java on the desktop or something.
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.
> 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.
If we're ragging on ancient Windows history, could Microsoft please make Notepad kinda usable? Here's two simple changes that would hugely reduce the incidence of me roaring at my machine when I remote into a server that doesn't have Notepad++ yet:
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.
> For the love of Cthulhu, don't rewrite it as a Modern app
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.
I personally find them to be slow to start. For example, the calculator app has a loading screen. A loading screen for a calculator! It's usually about second or half a second, but sometimes it is more. The Photos app has a similar slowness when opening that is annoying when browsing folders of photos.
The calculator also forces you to manually set focus on the "screen" label area before you can key anything. I guess some people may want to type numbers into the calculator app for some other purpose?
Biggest issue I have with them is that they don't support Drag and Drop.
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.
Just to clarify, not having Drag and Drop is not an API limitation (see [1]). Rather, they haven't implemented it yet in every place you'd expect to see it.
The ribbon was specifically designed for programs that have so many functions and features that the traditional menu+toolbar would be nigh-unusable (as evident in older Office versions where users often didn't even know that certain features existed). So I guess indeed, Notepad with probably ten different functions that could be exposed, can live just fine with a menu bar.
Not to mention that it takes ages to open a file that's even a few megabytes in size (as a programmer I wouldn't dare ask what's going on inside, for fear of nightmares). The irony is that wordpad both handles newlines properly, and can open large files. So it trumps notepad on almost everything.
Of course, by the time you've gotten to that point, you've probably installed a better editor.
When did Notepad start letting you open files greater than an arbitrary limit (I believe it used to be 50kb?) (Haven't used Windows on a machine daily since Windows 7)
And next year when ASP.NET 5 ships, we'll finally be able to use environment variables for appSettings [1] instead of the hacked up mess that web.config is right now.
Yes, all the time. Azure / EC2 all provide top class windows hosting. But for low cost shared I am stuck with arvixe and aspdiscount or so... But yeah I have only windows hosting over 10 years . Gives me everything PHP, python, .net , MySQL , mssql. I find Linux shared hosting too restricted. especially with sql server express edition...For me writing .net (actually vb.net) is way faster personally than even C# I use it all the time , I use c# only when some function is missing even then I use c# via library and still keep the vb.net. Though lately vb.net sample codes is very low but easy to convert from c#. Tried python like it but that 4 whitespace or whatever freaks me out. Currently on Go and Erlang learning path... but yeah IIS 8.0 excellent platform for low traffic websites
The asp.net team have taken something super simple, but opaque, and made it super complicated for no good reason.
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>
always felt like the Windows mechanism of having at least one non-ambiguously global place to set environment variables to be super useful to deal with (instead of the ubuntu '/etc/environment/', except when it's '.profile', except when it's '.pam_environment', except when its '.bashrc')
Baseless argument. Windows also splits the environment between the HKLM and HKCU hives. It just gives you a handy window to edit both at once.
.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.
I'm not against there being many different hooks in your average linux distro, but googling 'how to set environment variables in Ubuntu' gives you 20 different answers, with many conflicting statements between them.
I never heard of /etc/environment and ~/.pam_environment before, and thought /etc/profile was the place for variables for all users, with only .profile and .bashrc to check for user variables. Looks like Linux is going the Windows way by providing too many places to configure things.
Having worked with AIX fairly recently, I was under the impression that ~/.env was merely a common value for the ENV environment variable, which is a shell script that plays the same role for Korn shell (and possibly POSIX sh) as ~/.bashrc does for Bash. This page seems to support that interpretation: http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.... On the other hand, I think /etc/environment on Linux (not sure about AIX) and ~/.pam_environment are not shell scripts.
What's worse, Linux (or Unix) requires the user to re-login to make the changed environment variables take effect. Whereas in Windows they are applied immediately, so you don't have to re-login after changing PATH.
That's a neat trick, thanks for pointing me out. I've always wondered how Windows could have accomplished that. It's a shame that Linux doesn't have such an equivalent. If we are to do the same thing in Linux, a login shell (bash or zsh or even GNOME) would be the right place to implement?
I've wondered why they didn't fix this so many times over the years. Every time I saw that one inch wide, unresizable text input for the PATH or other variable, I got that feeling of exasperation you get when you know a company doesn't listen to its customers. It would have been the easiest thing in the world to do and yet it took over a decade to do it.
I dream that someday I can cut and paste from the command prompt. I mean, I'm really happy that Microsoft is actually making improvements to parts of windows that have been needlessly awkward for decades.
You can cut and paste from the command prompt if you go to properties and check the "Quick Edit Mode" option. It lets you highlight with the left mouse button and copy by simply clicking the right. w/o quick edit you first have to select 'Mark' from the context menu then you can highlight text to copy paste. It has worked this way as long as I can remember.
In Windows 10, you can use Ctrl+C to copy and Ctrl+V to paste. If they don't work, right click the command prompt titlebar, select Properties and then the Options tab, and turn on "Enable Ctrl key shortcuts". In this same properties page, you may also find "Enable line wrapping selection" and "Extended text selection keys" useful.
Because Ctrl+C was used for "interrupt" long before the concept of copy-paste came into being. Enter is often used to signify the positive end of an operation.
How about Ctrl+C? The meaning is unambiguous: If there is a selection, Ctrl+C is handled by the console host and copies the selection. If there is no selection, Ctrl+C is passed on to the running program which then does whatever it likes with it (i.e. in many cases terminate itself).
Your suggestion makes sense, but my previous question was referring to how Windows handles this. Do you know if it's possible to assign Ctrl+C to both operations for the Windows 10 command prompt?
That was a description of how Windows handles this. Basically, the current selection and those capabilities are part of the console host. Your application running in a console window has (to my knowledge) no idea of those features; it cannot tell whether there is a selection or not or what to do with it because they happen transparently a layer above your application (between your application and the window manager, essentially).
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.
And there is nothing more awkward than trying to manipulate file ACL's in those tiny dialogues that you can't resize. I would think that it would be easy to fix the resize problem, but its almost as if they had some compelling reason keep them at a fixed size.
I've never understood that either. Those are just Win32 windows, right? So you change a window-style flag, and it should become resizable, right? I'm tempted to go mess around and see if I can hook into those windows with COM somehow and twiddle some bits...
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.
> Maybe the rest of the dialog controls are all fixed dimensions and non-autosizable.
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?«.
Interesting that they default QuickEdit mode to on now. In Windows 2000 (supposedly), they had to roll a hotfix because some well-meaning engineer made the same change without thinking of backwards compatibility. [2] Kinda shows how times have changed.
[1] "One of the top requested changes we’ve received over the years is to have quick-edit mode enabled by default. Tada!"
I remember on a few occasions staring puzzled at some script at work, which was taking a lot more time to run, than normally.
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.
I still have the classic environment variables window and single line text boxes. Must be a setting somewhere...
However, regarding the command prompt, I unchecked 'use legacy console' and now I can do much more. Transparency is something I am used to in Blender3D and Linux. Now with Ctrl-Shift-+ or -, I can vary the transparency!
The linked post notes that the new environment variables stuff is in the preview build 10565. I presume you'll only get that build if you select the Insider build channel. I'm still on the standard release build 10240 which still has the old environment settings box.
No more rectangular console text selection? I've got to find a way to turn that on, I guess. My Win10 box is still doing the same old thing.
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 text selection, see my other comment in this thread and turn on the "Enable line wrapping selection".
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.
Yeah, there's a word wrap selection setting in win10.
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.
Hopefully there is no more maximum length that PATH could be. My last experience was with Windows 7, so maybe a lot has changed since then. Nothing more annoying than having a custom CMD shortcut that loads a script to add things to PATH that got truncated otherwise, and maintaining that script as new programs were installed and wanted to keep adding to PATH.
You're technically correct, but you're really underplaying how goddam troublesome it can be.
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.
Did you take a look at those Intel binaries they wanted on the PATH? They are all diagnostics tools that so far as I know aren't very useful to the average developer, much less the average consumer. There really doesn't seem to be a reason for Intel to add them to the PATH, because how often do people make support calls directly to Intel?
I just remove the Intel folders from my PATH (every time one of their drivers resmashes them into the PATH).
IIRC, it's more a problem with Microsoft making that there preferred way to make programs available in the shell rather than having a well-known user and system level locations places to which symlinks could be placed.
The preferred way is App Paths [1], it's just that there's not really a good UI for that and most people are used to Unix-style PATH environment variables so a lot of software depends on that that maybe doesn't actually need to and a lot of installers are built for that because the person building the installer didn't find the App Path tools but did find the Environment Variable smasher.
Also the fact that for compatibility reasons the CMD shell doesn't do App Path-based lookups, but in some ways that is an implementation detail (and what "start.exe" and its PS equivalent are for), and something that only really impacts shell-using developers.
Does the "Edit Text..." button still allow access to the old single-string version? If so, that would be good - nothing worse than making one thing easy to do, but making something else that used to be easy nearly impossible.
I don't have a windows laptop with bluetooth to test, but doesn't bluetooth work for this? I haven't used Airdrop though so I might be missing something. But for example I've used it to send from my mac to android tablet when the terrible osx/Android file manager program fails to work.
Edit: I think I fat finger downvoted parent, sorry
I never thought Windows would bring innovation in this dimension! I hated the PATH dialog for so many years so that I stopped hoping for anything better.
Maybe someday we will have a decent terminal window, too!
Now Mac OS X is the only major operating system without an easy way to modify environmental variables. Sure, you can edit your `.profile` or `.bashrc` or `.zhsrc`, but those settings do not carry over to your GUI applications, like the IDEs I am used to.
Applications are spawned by launchd, which is why changing shell environments doesn't get propagated to GUI apps. Use:
launchctl setenv MYVAR myval
to change the launchd environment and those of the launched apps. These changes are lost after a reboot, unless you configure launchd via a plist file with these values. And there's a graphical plist editor for those that really like guis for these things.
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...
Which is weird because it used to. But ~/.MacOSX/environment.plist (easily edited in the plist editor) got deprecated and isn't used any more.
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.
I answered an interesting SO question on that recently, which asked how to save and restore the environment in PowerShell. Turns out, the environment being in a PSDrive helps very much with that because you can treat the variables just like you treat files:
TempleOS has something like a set of environment variables for each task - if the user asks for a variable and it isn't found, then the parental task's variables are checked, followed by the next parental task's variables etc., all the way up to Adam, which would be like global environment variables.
Aren't environment variables kind of a bad thing in Windows? They're global so installing an application that twiddles with them could break another application. Isn't that what we had the registry for and now AppData?
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?
It took them only 25 years to improve the UI (since early days of WinNT 3.1). Unsexy parts of the OS are rarely touched, e.g. the Windows system font folder import dialog used to look like a Win16 file open dialog even in Win7.
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.
I hope this means that somebody also fixes KB329308, which I'm pretty sure was still around in Windows 7 (unless it already got fixed in 8/8.1) [1]. It's pretty easy to get bitten by this when setting up Java build tools on Windows.
The UI was bad, but the length limit is my biggest grief with the path environment variable. A lot of useless drivers and software feel that they need to have their own entry and if you have enough software installed in a box, very bad things will happen when you reach that limit, starting with the windows UI falling apart.
I don't know why everyone says copy paste from/to an text-editor... I copied a path into my clipboard and wrote ;{past-shortcut} and click ok. And the path was added.
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
That's not true at all. In the corporate world Windows is still the default because of many the tools used to make large organisations flow are available only on Windows. OSX and Linux is used a lot as well, but it's most common in small organisations and new "hipper" companies.
This works for any application started by Explorer (which also means the task bar and start menu). Windows broadcasts a message that the environment has changed and Explorer listens and updates its environment accordingly.
(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.