Skip to content

setup.sh's documented one-liner (curl … | bash -s -- …) never asks for the yes, not even in the person's own terminal, because its stdin is the pipe, so the front door cannot be completed without --yes #492

Closed

Description

@brettheap

Lane: openreposhape-3 (openRepoShape-3)

(lane openRepoShape-3, 2026-10-12T22:37Z) Found by lane 3's writer for #476 while measuring it (PR #491). Lane 3 claims it; it needs a design word from Brett Heap first (see the end).

What is wrong. README's setup section leads with the one-liner, and AGENTS.md section 2 tells an assistant to run it:

curl -fsSL https://raw.githubusercontent.com/opensoft/openRepoShape/main/setup.sh \
    | bash -s -- --org <org> --project <Project> ...

It is to be run without --yes, so that setup asks and the human types yes. But piped into bash, the script's stdin IS the pipe, and so is the stdin of setup-project.py, which setup hands over to. So setup never asks, not even in the person's own terminal. It prints the plan, then refuses:

REFUSED: this will create THREE repositories and there is no terminal to confirm on. Re-run with --yes if you mean it.

It exits 2.

Measured in a pty standing in for a person's terminal, on main 8782333 and on #491's head alike:

form asks? result
cat setup.sh | bash -s -- … no exit 2, the refusal above
bash <(cat setup.sh) … yes Type yes to continue:, and no gives exit 1 "not confirmed"
./setup.sh … in a checkout yes prompt
a downloaded setup.sh, or the openRepoShape command yes prompt

The pty runs used the checkout hand-over. The self-bootstrap path (no checkout; it clones and hands over) needs the same measurement. Its stdin is the same pipe.

So, as written, the documented front door cannot be completed without --yes. That is the flag AGENTS.md's first rule forbids an assistant, and README offers it to a person only as a non-default. setup-project.py's own comment already knows this for Windows ("a script that arrived on stdin has an exhausted stdin … That is exactly why the README's Windows path DOWNLOADS the file first"). The bash path never got the same treatment.

The choice (Brett's).

  1. Read the answer from the terminal (recommended). When stdin is not a terminal but /dev/tty opens, setup.sh (or setup-project.py) reads the confirmation from /dev/tty. That is the usual pattern for curl | sh installers. The documented one-liner keeps working for a person, and an assistant's shell, which has no controlling terminal, still refuses, so setup.sh in an AI assistant's shell (no terminal) refuses with "Re-run with --yes", the flag AGENTS.md's first rule forbids the assistant, and AGENTS.md gives no other route #476's route applies. Windows has no /dev/tty; its path already downloads the file.
  2. Change the front door. README and AGENTS.md lead with bash <(curl -fsSL …) …, which keeps stdin attached. Smaller in code, but every copy of the command changes, and <(…) needs bash, not sh.

Either way, tests drive the one-liner form through a pty and check that it asks.

Why v1.0.0. It is the first command in README and the first procedure in AGENTS.md. Proposed P1.

Parent: #459. Related: #476 (PR #491).

Activity

  1. added this to the v1.0.0 milestone on Oct 12, 2026
  2. brettheap commented on Oct 12, 2026

    @brettheap
    ContributorAuthor

    CLAIMED — lane openRepoShape-3, session 20b4ae33-927d-4b5d-a856-e7e467ea11b2@Eagle, 2026-10-12T22:38:22Z, for #492

    Logged in lanes/log/openRepoShape-3.md at 28cc3a3f250b9dd4a44ad85d8ed255c0cfa3bb79.

    The three reads (lane-collision-protocol Rule 1):

    1. existing `CLAIMED —` comments on opensoft/openRepoShape#492:
       none
    2. `gh pr list --repo opensoft/openRepoShape --state all --search "#492"`, kept where the row or its body names `#492`:
       none
    3. `git ls-remote --heads git@github.com:opensoft/openRepoShape` branches naming `492` as a whole token:
       none
    
  3. brettheap commented on Oct 12, 2026

    @brettheap
    ContributorAuthor

    (lane openRepoShape-3, 2026-10-12T22:55Z) Ruling, recorded: Brett Heap, at 2026-10-12T22:54:07Z, chose between this issue's two options: "#492: go with /dev/tty, option 1".

    So the fix is option 1:

    Tests drive the one-liner through a pty and check that it asks. Lane 3 holds the issue, and its writer starts when the lane resumes after the account swap. It must compose with #491, which rewords the same refusal.

  4. added 4 commits that reference this issue on Oct 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions