Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add wrong_hyphen_before_subcommand rule #977

Merged
merged 15 commits into from
Aug 7, 2021

Conversation

yotam180
Copy link
Contributor

@yotam180 yotam180 commented Oct 12, 2019

This rule corrects two common mistakes:

  1. Omitting the space between the command and its flag arguments (e.g. ls-la instead of ls -la)
  2. Placing a hyphen rather than a space between a command and its subcommand (e.g. apt-install and not apt install)

Regarding issue #975

@yotam180
Copy link
Contributor Author

I didn't abandon this PR to fail, currently working on mock-ups for the man-page retrieving functions.

Comment on lines 142 to 148
if subcmd in synopsis or find_subcommand(manpage, cmd, subcmd):
# We are dealing with an accidentally added hyphen
return command.script.replace('-', ' ', 1)

else:
# We are dealing with a missing space
return command.script.replace('-', ' -', 1)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a simpler version of the entire rule would be better.

IMO, TheFuck should delegate that choice to the user.

Following the path the current rule is going, the failed command apt-install foo would get two suggestions, apt -install foo and apt install foo, among others.

Thing is that the former – apt -install foo – already gets suggested by the existing missing_space_before_subcommand rule.

Looking at it that way, all the wrong_hyphen_before_subcommand – or even an augmented missing_space_before_subcommand – rule would have to do is replace the hyphen with a space.

What you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following your suggestions, I tried to simplify the rule down. I'm afraid I over-simplified it (since it may now suggest git hello as a replacement to git-hello even though hello is not a legitimate subcommand for git).

I'd be happy to hear your opinion about that. Should rules do above and beyond to verify their command suggestions? Or should the current way of command checking be the norm?

Anyway, another issue I have is that the rule now should not try to handle cases such as ls-la (-> ls -la), but as it doesn't check the manpages anymore there is no way for the rule to determine if la is a subcommand or flags. Thus it suggests ls la. Now the issue is that the priority of the rule (as I see it) should be lower than no_command's priority, and the missing_space_before_subcommand is higher than no_command's. Thus the wrong_hyphen_before_subcommand shadows the missing_space_before_subcommand rule.

Any suggestions?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better if the rule does not try to be super smart. In the same sense as missing_space_before_subcommand. Let it suggest any fix that has some probability to work. The user decides to accept. That's my own opinion.

Regarding the priority, I think it should be set to 3900. It's more close to missing_space_before_subcommand than to no_command.

@nvbn wanna chime in, pal?

README.md Outdated
@@ -299,6 +299,7 @@ following rules are enabled by default:
* `vagrant_up` – starts up the vagrant instance;
* `whois` – fixes `whois` command;
* `workon_doesnt_exists` – fixes `virtualenvwrapper` env name os suggests to create new.
* `wrong_hyphen_before_subcommand` – adds or omits dashes improperly placed (`ls-la` -> `ls -la`, `git-log` -> `git log`, etc.)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description lacks an update.

if '-' not in command.script_parts[0] or command.script_parts[0] in get_all_executables():
return False

cmd, subcmd = command.script_parts[0].split('-')[:2]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that subcmd isn't necessary anymore, this line could be changed to:

Suggested change
cmd, subcmd = command.script_parts[0].split('-')[:2]
cmd = command.script_parts[0].split('-', 1)[0]


@sudo_support
def get_new_command(command):
return command.script.replace("-", " ", 1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is dangerous, there might be other hyphens. You really should only replace the hyphen in script_parts[0].

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would agree if the match function wouldn't require a hyphen in command.script_parts[0].

return False

cmd, subcmd = command.script_parts[0].split('-')[:2]
if cmd not in get_all_executables():
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could simply be :

return cmd in get_all_executables()

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yotam180, can you please address this remark?

Suggested change
if cmd not in get_all_executables():
return cmd in get_all_executables()

This along with the one a few boxes above:

-    cmd, subcmd = command.script_parts[0].split('-')[:2]
+    cmd = command.script_parts[0].split('-', 1)[0]

@scorphus scorphus self-assigned this May 9, 2020
@scorphus scorphus added this to the 3.31 milestone May 10, 2020
@scorphus scorphus force-pushed the dev/wrong-hyphen branch 2 times, most recently from d4bae68 to 2a9d92f Compare August 7, 2021 20:59
Copy link
Collaborator

@scorphus scorphus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for ccontributing, @yotam180! 👍 :shipit:

You may want to check the last few commits.

@scorphus scorphus merged commit 2a166a7 into nvbn:master Aug 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants