Weird argument passing when running shell commands

[htogta]

I noticed that when the && operator is used in a shell command after Ctrl-b, it seems like everything after the && operator just gets passed as an argument to the previous command rather than those commands being executed separately.

For example, doing Ctrl-b and inputting echo "one" && echo "two" ends up printing one && echo two. This happens when doing things without the string literals as well- for example, running date && date has the first date command fail and print an "extra operand 'date'" error. These same issues happen with run.

I'm using version 2.0.15-dev.245, but it doesn't seem like any commits since this version have affected this issue.

[Neko-Box-Coder]

Yeah, this is because of how we are handling shell commands. We don't go through the shell, but instead run the program directly. So in this case we are passing whatever you wrote to echo directly

For now, a workaround would be sh -c "echo \"one\" && echo \"two\""

[htogta]

We don't go through the shell, but instead run the program directly.

@Neko-Box-Coder just out of curiosity, is there a specific benefit to running the programs directly rather than just calling upon the shell?

[Neko-Box-Coder]

@Neko-Box-Coder just out of curiosity, is there a specific benefit to running the programs directly rather than just calling upon the shell?

I didn't phrase it right, this is a bug since we do explicitly say "runs the given shell command in the background" in the help file.

Alternatively, you can run the term command to pull up the terminal in micro.

Anyway, to answer your question, running the program directly is better sometimes if you don't want to worry about sanitizing input which can be run by the shell by surprise.

For example, if you are trying to run a grep command on a highlighted text automatically (maybe with a plugin or something).

This might be problematic if you highlighted the text like " && rm -R ./ && echo " by mistake (somehow), then it could turn into grep "" && rm -R ./ && echo "" when substituting the highlighted text into the command grep "<highlighted text here>"

But clearly this concern doesn't apply here since the user should know what they are doing and we are supposed to do whatever the doc said.

The fix should be fairly simple by just running via the shell instead.

[niten94]

Anyway, to answer your question, running the program directly is better sometimes if you don't want to worry about sanitizing input which can be run by the shell by surprise.

But clearly this concern doesn't apply here since the user should know what they are doing and we are supposed to do whatever the doc said.

Yes. Specifically, I think they should quote arguments as a practice, since they might accidentally leave problematic arguments unquoted when using a shell.

Plugin developers should also use functions like ExecCommands() if they want to avoid any issue on passing arguments.

The fix should be fairly simple by just running via the shell instead.

Edit: I'm sorry, I didn't realize this issue was referring to Ctrl-b which is easy to modify without issues. My response below is about commands like > run, however #3884 is affected by the issue I mentioned below.

Details

Yes, but I don't think it's simple to receive the exact command without the user quoting it as one argument. I believe we should preserve it, even if this will mostly only occur on less usual commands.

For example, > textfilter cut -d '|' -f2 may not run as expected and cause confusion. After the command parser splits the arguments, it cannot be determined if | was quoted or not. I haven't tested anything but I believe such will happen with #3884.

As a soluton, it may seem like the commands in Micro (run, textfilter, term) could try to "fix" the input. However, there are a lot of edge cases including $SHELL being set to a shell with syntax different from sh.

I can understand that either may not be desired, but there are 2 solutions I rather suggest:

• Run the program directly if passed in the > prompt. If none, switch to a prompt that runs the command under the user's shell. It may be displayed like (shell) run: for example. This also needs the help page to be slightly more accurate
• As a special case on commands like run, change HandleComand() to directly pass the rest of the input as one string argument

[htogta]

Run the program directly if passed in the > prompt. If none, switch to a prompt that runs the command under the user's shell. It may be displayed like (shell) run: for example. This also needs the help page to be slightly more accurate

As a special case on commands like run, change HandleComand() to directly pass the rest of the input as one string argument

The idea of having a special case for run and similar stuff is a better one, imo- what I did in the pull request was originally a kinda hacky way of going about that, I might play around with cleaning it up more and submitting a new pull request. Either that or, yeah, just updating the help page to reflect how it actually behaves (but then this just goes from being a "bug" issue to a "feature request" issue lol).

I have been using the modified build of micro that contains the change I made in the pull request lately, and thus far haven't encountered any issues though. I'll test out the textfiler issue though.

[niten94]

The idea of having a special case for run and similar stuff is a better one, imo

I think we should go with special parsing. It's easier to implement than I thought and likely less confusing than switching prompts. Instead of using go-shellquote to retrieve both command name and arguments, HandleCommand() could determine the command name using simple string indexing and functions.

I might play around with cleaning it up more and submitting a new pull request.

It's not easy to learn Git, but FYI you could submit the PR from a new branch other than master. At least on GH, it's also fine to delete any branch after its PR is merged or closed.

(but then this just goes from being a "bug" issue to a "feature request" issue lol).

Yeah, but it doesn't really matter since we don't categorize issues yet. Adding features can fix bugs at the same time as well :)

I have been using the modified build of micro that contains the change I made in the pull request lately, and thus far haven't encountered any issues though. I'll test out the textfiler issue though.

Sorry, I didn't read properly and my comment is unclear.

Since > run was mentioned, I thought someone will suggest changing > term and > textfilter as well. Both are currently unaffected, but probably shouldn't differ with > run on whether shell is used.

This example is similar and an error can be reproduced with #3884: > run echo '&File|&Edit|&View' | cut -d\| -f3

Due to syntax like && being passed to the shell with > run, a user may expect they can use shell syntax. At least to me, it would be slightly unpleasant to realize that existing shell syntax would be interpreted differently.