Do you want to work on this issue?
You can request for a bounty in order to promote it!
Make extension optional on Windows? #1
sindresorhus posted onGitHub
Currently, you have to include the extension if you want to kill an application.
Eg. fkill('notepad.exe')
Would be nice if you just do fkill('notepad')
.
If the user did fkill('notepad')
, it could first try killing notepad
, then notepad.exe
if that didn't work.
Would love some thoughts on this from Windows users.
I haven't use windows in over a year. But I remember we've sometime had to append the .exe (or .cmd) to execute/kill programs.
I remember having to run grunt as grunt.cmd
in some context.
I don't have any technical knowledge about this process. But I think the suggestion is reasonable.
I've been using Windows some lately but wouldn't call me the typical Windows user so I would like this change. I'm not sure there ever is an application that doesn't have the .exe
extension either.
@MarkTiedemann, could use your expertise here too :)
I'm not sure there ever is an application that doesn't have the
.exe
extension either.
Well, it may not be common, but you'd be suprised how many applications use different extensions (see: list of executable file extensions), the most known one, apart from .exe
, being .com
, I guess.
On another note, to run an executable file, an extension is required in some cases - literally, any extension. You can name your executable program.doesntlooklikeanexe
, and it's still gonna run fine. As far as I know, the loader just checks the first two (or a few more) bytes of the file, and from that, determines whether it's an executable file or not.
Then again, there's the whole issue of the Windows Subsystem for Linux with Bash on Ubuntu on Windows, which many Node devs on Windows use these days. I have no idea which rules apply there.
In this respect, I think there's not really a perfect technical solution available here.
However, I do think that the suggestion of trying to kill without extension first, then adding .exe
if the previous attempt failed, is the simplest, most intuitive, best, and therefore, most fabulous solution from a user perspective.
We might also think about trying to kill both (with and without extension) at the same time to reduce the "waiting period" (if the first attempt failed). In any case, I guess we need proper error handling as well as kill confirmations to make users of this module truly happy.
I think we could use PATHEXT to get the extensions to try. It's going to be .exe
in 99% of cases though, so should definitely try that first.
Totally forgot about PATHEXT, thanks for reminding me!
So when executing a command that does not contain an extension, cmd
uses the value of PATHEXT to determine which extensions to look for, and in what order (.com
takes precedence over .exe
, by the way).
So you could say extensions are already optional on Windows!
That is when executing, but we're trying to kill here.
So the real issue here is with the taskkill
inplementation that requires the extension.
In that case, we should use the filter option and add a .*
to the process the user is trying to kill (e.g. /fi "imageName eq notepad.*"
) to reflect the optionality of the extension. Or, even better, we could add multiple filters based on PATHEXT. Haven't tested this yet, but I think this is probably the right direction to go.
Cool. Let's explore that.
I just tested it - unfortunately, multiple filters cannot be combined (when adding two filters for image names both must be true which, of course, is impossible). So we can't kill with filters based on PATHEXT
.
As I said earlier, if there's no extension, we could add imageName eq {{userInput}}.*
as a filter. However, there are images that do not have an extension in their name - so suddenly you couldn't kill them anymore.
To prevent that, we could do imageName eq {{userInput}}*
. In that case, however, we would also kill unrelated images that start with the same name.
Therefore, I think the best solution would be to just allow users to set the filter. Right now the default in the tasklist module is to use /im
. Instead we should do /fi "imageName eq {{userInput}}"
. Then you could do fkill notepad*
(or fkill note*
, or fkill *pad
). :)
Not sure if this change would require changes to the interface of the taskkill
Node module.
Hmm, a simpler way would just be to say that you can kill only .exe files without using an extension. We would then just try to kill first without extension and then with .exe
. What do you think? I'm trying to solve the 95% use-case here in the simplest way possible.
I can't imagine when you'd actually want fkill note*
. Sounds risky. Suddenly you quit an important unrelated process that starts with the same prefix.
We would then just try to kill first without extension and then with
.exe
. What do you think?
If we spawn 2 times anyway, we could spawn tasklist /fi "imagename eq {{fileWithoutExtension}}*"
and then kill based on the result so we support more extensions than just .exe
.
Then again, we could just kill based on the filter in the first place and wouldn't have to spawn twice.
In this case, technical correctness and performance together weigh more than the 95% use-case, IMHO.
I can't imagine when you'd actually want
fkill note*
. Sounds risky. Suddenly you quit an important unrelated process that starts with the same prefix.
Well, I don't have any note taking app on my system, so it doesn't sound risky to me. :) Still, do you think fkill notepad*
would be risky?
I guess I'm a big fan of the *
filter syntax. I use it myself regularly.
For example, for killing related tasks: I'm running the World Community Grid using BOINC on my system. Since it uses a lot of CPU, I sometimes kill it when I need the CPU power for something else. It runs boincmgr.exe
, boinc.exe
, and boinctray.exe
, so I simply use a boinc*
filter to kill all 3 in 1 shot.
Another use case where I have used the filter syntax before is some-exe-with-a-super-long-or-complicated-name-where-im-too-lazy-to-type-the-name-fully-myself.exe
. In my case, the program had a long name and, on top of that, a postfix with the version number, the build number, and an environment string (prod
or dev
). It was quite handy to kill with filters, e.g. {{first3CharactersOfTheName}}*dev*
.
In case anyone is interested in a primitive, light-weight alternative to fkill
on Windows, I have the following files in my PATH:
ulist.cmd
@echo off
tasklist /fi "imagename eq %1*"
ukill.cmd
@echo off
taskkill /fi "imagename eq %1*" /f
They are basically my 95% use-case approach; works like a charm! :)
If we spawn 2 times anyway, we could spawn tasklist /fi "imagename eq {{fileWithoutExtension}}*" and then kill based on the result so we support more extensions than just .exe.
I like that idea.
Then again, we could just kill based on the filter in the first place and wouldn't have to spawn twice.
Then we risk killing something the user didn't intend to. We would also have to document the behavior and it would be inconsistent with how it works on macOS and Linux.
Well, I don't have any note taking app on my system, so it doesn't sound risky to me. :) Still, do you think fkill notepad* would be risky?
You could have an unrelated process called noteworthy
. The point wasn't that exact word, but rather it's very easy to get lazy and use less and less characters. Suddenly you're only using foo
to kill foobar
, and then there's a process you didn't even know about called foocow
. Filters might be be useful. Just not as implicit or default behavior.
I guess I'm a big fan of the * filter syntax. I use it myself regularly.
I'm not saying we couldn't have that for fkill
, but that's a separate discussion and would have to be implemented for macOS and Linux too.
@issuehunt has funded $60.00 to this issue. See it on IssueHunt
@0maxxam0 has funded $2.00 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.
If anyone wants to work on this, see the previous attempt and feedback: https://github.com/sindresorhus/fkill/pull/32 and https://github.com/sindresorhus/fkill/pull/43.
Fund this Issue
Pull requests
Recent activities