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 shell

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 ';' 

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 xfdesktop

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.

[1] http://www.rapidee.com/en/about

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.