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

Let read builtin take a custom prompt string #802

Closed
terlar opened this Issue May 21, 2013 · 10 comments

Comments

Projects
None yet
8 participants
@terlar
Contributor

terlar commented May 21, 2013

Right now it only takes a function name which is a little bit cumbersome if you want to use a custom prompt for a specific use case. The worst part is you have to come up with some name for your prompt and you litter your functions.

Current use case:

function dangerous_function
  function continue_prompt
    echo 'Do you want to continue? [Y/n]'
  end

  echo 'I will do dangerous stuff'
  read -l -p continue_prompt continue

  if test $continue = 'Y' -o $continue = 'y'
    echo 'Do dangerous stuff'
  end
end

If we let -p take a string instead people could use a function if they want by using parenthesis, -p (continue_prompt).

function dangerous_function
  echo 'I will do dangerous stuff'
  read -l -p 'Do you want to continue? [Y/n]' continue

  if test $continue = 'Y' -o $continue = 'y'
    echo 'Do dangerous stuff'
  end
end
@rominf

This comment has been minimized.

Show comment
Hide comment
@rominf

rominf Apr 4, 2014

Contributor

I think it can be closed as it already implemented.

Contributor

rominf commented Apr 4, 2014

I think it can be closed as it already implemented.

@xfix

This comment has been minimized.

Show comment
Hide comment
@xfix

xfix Apr 4, 2014

Member

@rominf: Huh? Aware of any feature to do so, other than read -p 'echo "Do you want to continue? [Y/n]"'?

Member

xfix commented Apr 4, 2014

@rominf: Huh? Aware of any feature to do so, other than read -p 'echo "Do you want to continue? [Y/n]"'?

@rominf

This comment has been minimized.

Show comment
Hide comment
@rominf

rominf Apr 4, 2014

Contributor

Sorry, I misread issue. 😞 Yes, you are right. I wish that feature too.

Contributor

rominf commented Apr 4, 2014

Sorry, I misread issue. 😞 Yes, you are right. I wish that feature too.

@kballard

This comment has been minimized.

Show comment
Hide comment
@kballard

kballard Sep 22, 2014

Contributor

It actually takes arbitrary fishscript, so you can use

function dangerous_function
  echo 'I will do dangerous stuff'
  read -l -p 'echo "Do you want to continue? [Y/n] "' continue

  if test $continue = 'Y' -o $continue = 'y'
    echo 'Do dangerous stuff'
  end
end

Although I do agree that taking a prompt string is easier and more common.

Contributor

kballard commented Sep 22, 2014

It actually takes arbitrary fishscript, so you can use

function dangerous_function
  echo 'I will do dangerous stuff'
  read -l -p 'echo "Do you want to continue? [Y/n] "' continue

  if test $continue = 'Y' -o $continue = 'y'
    echo 'Do dangerous stuff'
  end
end

Although I do agree that taking a prompt string is easier and more common.

@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Feb 12, 2016

Contributor

[crossposting from #2166 where it didn't really belong]
Don't know if a backward-incompatible change can be justified here but:
I wish the current command-to-execute behavior was named something like --prompt-cmd rather than --prompt, -p. Named "prompt" it really sounds like it takes a static string, plus that's exactly what read -p does in bash.
In fact, I don't see any use for the command-to-execute functionality. It's not to be dynamic - I just tested with 'date -Ins' and neither --prompt nor --right-prompt commands are ever re-run during editing.

Contributor

cben commented Feb 12, 2016

[crossposting from #2166 where it didn't really belong]
Don't know if a backward-incompatible change can be justified here but:
I wish the current command-to-execute behavior was named something like --prompt-cmd rather than --prompt, -p. Named "prompt" it really sounds like it takes a static string, plus that's exactly what read -p does in bash.
In fact, I don't see any use for the command-to-execute functionality. It's not to be dynamic - I just tested with 'date -Ins' and neither --prompt nor --right-prompt commands are ever re-run during editing.

@cben

This comment has been minimized.

Show comment
Hide comment
@cben

cben Feb 12, 2016

Contributor

Actually the standard gradual-deprecation strategy is possible here too:

  1. Add unambiguous --prompt-string and --prompt-command options (plus --right-... variants).
    -p, --prompt still mean --prompt-command but documentation warns they might change meaning in the future, and recommends the new unambiguous options.
  2. ... wait however long we're comfortable with (possible to stop here)...
  3. Make -p, --prompt still mean --prompt-command but also print a warning.
  4. ... wait more ...
    (In principle, could add here a stage where -p, --prompt are an error, hardly worth it in this case.)
  5. Redefine -p, --prompt to mean --prompt-string.

I'm willing to do the work if you think the gain is worth it.

Contributor

cben commented Feb 12, 2016

Actually the standard gradual-deprecation strategy is possible here too:

  1. Add unambiguous --prompt-string and --prompt-command options (plus --right-... variants).
    -p, --prompt still mean --prompt-command but documentation warns they might change meaning in the future, and recommends the new unambiguous options.
  2. ... wait however long we're comfortable with (possible to stop here)...
  3. Make -p, --prompt still mean --prompt-command but also print a warning.
  4. ... wait more ...
    (In principle, could add here a stage where -p, --prompt are an error, hardly worth it in this case.)
  5. Redefine -p, --prompt to mean --prompt-string.

I'm willing to do the work if you think the gain is worth it.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 12, 2016

Please see #2166 (comment) for a solution implemented in userland.

ghost commented Feb 12, 2016

Please see #2166 (comment) for a solution implemented in userland.

@krader1961 krader1961 self-assigned this Mar 25, 2017

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Mar 25, 2017

Contributor

The current read command API is due to how fish interactive mode works. In other words it is exposing an implementation detail solely because it is used by the read command. Rather than because that implementation detail makes sense in this context.

Outside of the read command the default prompt for reading user input is constructed by calling the fish_prompt function. So the person who implemented read simply required a function name or fish script to be compatible with the implementation for prompting the user for input at the shell's "top level". That is a generalization that is pointless for the read command. Which is to say 99.999% of time anyone invoking read -p does not need the prompt to change based on current conditions. All of the core fish script uses of read -p would work fine if they passed a static string.

We can't break backward compatibility without at least one major release. We can, however, add a saner read flag that accepts a simple string for the left prompt. Such as a -P and --prompt-string flag as proposed by @cben.

Contributor

krader1961 commented Mar 25, 2017

The current read command API is due to how fish interactive mode works. In other words it is exposing an implementation detail solely because it is used by the read command. Rather than because that implementation detail makes sense in this context.

Outside of the read command the default prompt for reading user input is constructed by calling the fish_prompt function. So the person who implemented read simply required a function name or fish script to be compatible with the implementation for prompting the user for input at the shell's "top level". That is a generalization that is pointless for the read command. Which is to say 99.999% of time anyone invoking read -p does not need the prompt to change based on current conditions. All of the core fish script uses of read -p would work fine if they passed a static string.

We can't break backward compatibility without at least one major release. We can, however, add a saner read flag that accepts a simple string for the left prompt. Such as a -P and --prompt-string flag as proposed by @cben.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Mar 26, 2017

Contributor

I want to reinforce that the current -p / --prompt flag accepts arbitrary fish script. In fact the default prompt if you don't specify one is this:

set_color green; echo -n read; set_color normal; echo -n "> "

Nonetheless, that flexibility is overkill most of the time and simply confuses the script writer trying to prompt someone for input. So it makes sense to provide a simpler UI that satisfies 98% of the read uses.

Contributor

krader1961 commented Mar 26, 2017

I want to reinforce that the current -p / --prompt flag accepts arbitrary fish script. In fact the default prompt if you don't specify one is this:

set_color green; echo -n read; set_color normal; echo -n "> "

Nonetheless, that flexibility is overkill most of the time and simply confuses the script writer trying to prompt someone for input. So it makes sense to provide a simpler UI that satisfies 98% of the read uses.

@krader1961 krader1961 modified the milestones: 2.6.0, fish-future Mar 26, 2017

develop7 added a commit to develop7/fish-shell that referenced this issue Apr 17, 2017

@Pysis868

This comment has been minimized.

Show comment
Hide comment
@Pysis868

Pysis868 Jun 16, 2017

woo!!

GitHub - fish-shell/fish-shell - fish 2.6.0 (released June 3, 2017):

  • ...
  • read supports a new --silent option to hide the characters typed (#838), for when reading sensitive data from the terminal. read also now accepts simple strings for the prompt (rather than scripts) with the new -P and --prompt-str options (#802).
  • ...

Pysis868 commented Jun 16, 2017

woo!!

GitHub - fish-shell/fish-shell - fish 2.6.0 (released June 3, 2017):

  • ...
  • read supports a new --silent option to hide the characters typed (#838), for when reading sensitive data from the terminal. read also now accepts simple strings for the prompt (rather than scripts) with the new -P and --prompt-str options (#802).
  • ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment