A warning/confirm field that shows a confirm prompt before proceeding

[ianwalter]

trafficstars

I think it would be cool if there was a way to specify a warning before executing commands in which the user may not fully understand the consequences. It could look like:

reset:
  desc: Reset environment from scratch
  warning: This will remove all data and environment customization. Are you sure you want to do this?

And then before executing task reset it would prompt the user with a confirm prompt that looks like:

This will remove all data and environment customization. Are you sure you want to do this? [y/N]

[andreynering]

Hi @ianwalter,

This is probably already possible somehow using bash inside a command.

I'll keep this open for discussion if this is worth implementing. It would not be hard.

[ianwalter]

@andreynering That's a good point. I could use read and then conditionally execute a shell command based on the user's response. The only problem is that on confirm I want to execute a series of tasks. I could just create a new task and then execute something like task resetConfirmed but that would expose the command in help (and in the CLI) which is not really a good UX. Feel free to close this though if you want to prioritize being lean over UX.

[andreynering]

@ianwalter Take a look at the silent option, you can prevent a command to be printed.

I still consider to accept a patch for this, though.

[parkerduckworth]

Hey @andreynering is this something still being considered?

Having this command in a cmds block fails to run:

cmds:
  - read -p "Display me as a prompt. Continue? (y/n)"

And produces this oddity:

read: invalid option "-p"

If you still think adding a warning or prompt block would be a good addition to this project I would gladly take on the task (😉) to write the patch.

[andreynering]

@parkerduckworth That should be possible once https://github.com/mvdan/sh/issues/551 is implemented upstream.

[AnonLibre]

Example prompt implemented with the dialog command in case someone needs a confirmation prompt until this feature is discussed.

version: '3'

tasks:

  confirm:
    desc: "Executes a dangerous command.."
    cmds:
      - |
        dheight=10 \
        ; dwidth=60 \
        ; dialog \
          --defaultno \
          --backtitle "Dangerous Command Title" \
          --yesno \
            "Do you really want to execute the dangerous command?" \
          ${dheight} \
          ${dwidth}
      - echo "Executing dangerous command."

[core-dev-crypto]

Hello @andreynering ,

I would like to contribute to the project and improve my Go skills

I think it is a good issue to start. Do you mind assigning it to me ?

My idea is to implement a function from Outf that return the string read from STDIN. I have two doubts:

• Which kind of input? Buffered (need a CR) or unbuffered (like a keypress). I think to use buffered input so the user must press ENTER to confirm.

• Where put the function? I think I put internal / logger.go even though it's not really a logging function (it ask a input from the terminal).

[wtfzambo]

Hey @andreynering is this something still being considered?

Having this command in a cmds block fails to run:

cmds:
  - read -p "Display me as a prompt. Continue? (y/n)"

And produces this oddity:

read: invalid option "-p"

If you still think adding a warning or prompt block would be a good addition to this project I would gladly take on the task (😉) to write the patch.

I know this is kind of necrothreading, but to be fair, the -p flag works for me, look:

[pd93]

I know this is kind of necrothreading

Not really, this still hasn't been implemented and I think it can still add value to Task 😛 A couple of things have changed since this thread was last updated:

---

the -p flag works for me

Yep, mvdan/sh now supports read -p, so you should be able to use this just fine. Related:

• https://github.com/go-task/task/issues/314
• https://github.com/mvdan/sh/pull/722

---

I could just create a new task and then execute something like task resetConfirmed but that would expose the command in help (and in the CLI) which is not really a good UX.

We now have internal tasks which solves this.

---

Also a recent related discussion: #1033.