Request: Dump to stdout

[ParadaCarleton]

Sometimes I call a command and the output is piped into a pager, but I didn't want this (I might just want that to go into stdout). In those cases, it'd be super helpful if some shortcut would dump whatever's in moor into the stdout.

As a bonus, we could combine this with filtering for an interactive filter-then-pipe workflow.

[walles]

Pressing v will solve at least part of this, it opens the current file's contents in your configured $EDITOR.

Can you try that and see how that works out for you?

[ParadaCarleton]

Pressing v will solve at least part of this, it opens the current file's contents in your configured $EDITOR.

Can you try that and see how that works out for you?

Unfortunately doesn't work for my use-case, although it's a very nice feature :)

[walles]

So is it something like this you want to do?

cut -f2- file.txt | moor | wc -l

And the expected behavior is:

1. get to view the cut output in the middle
2. after you exit mooryou get your line count printed

[ParadaCarleton]

Yep, exactly! Although implementation-wise, I'd suggest making this use a shortcut (maybe "ctrl+p" for "print") instead of just having it detect whether the output is being piped into something else, so the user can decide after reviewing whether they want to have it piped into the next step.

[walles]

This might be doable by having moor using stderr rather than stdout for its display. I think terminals should be fine with that.

Then after exit, moor could dump (or not dump) the buffer contents to stdout.

That said, I'm personally not super interested in this, so it's not something I will prioritize.

[Lockszmith-GH]

Not sure writing to stderr is the correct approach.
@ParadaCarleton have you tried using television or fzf for this instead?

[ParadaCarleton]

Not sure writing to stderr is the correct approach. @ParadaCarleton have you tried using television or fzf for this instead?

Unfortunately wouldn't work. I've had two use cases for this:

1. When working with LLMs, they'll often call a tool that pipes into a pager; the issue is they can't see the pager, and the tool doesn't write to stdout.
2. When running someone else's code that calls tools like git or jj with an optional pager, assuming the pager is disabled, it's a pain having to turn the pager option on and off every time I use their code.

[walles]

I feel I'm missing something here, can you give a concrete example that I can follow?

When working with LLMs, they'll often call a tool that pipes into a pager; the issue is they can't see the pager, and the tool doesn't write to stdout.

When I ask Claude or CoPilot to do some git operation, they make sure to call git in a way where they can see the output. I think tuning the LLM interaction here might be a better way forward.

Or am I missing something here?

When running someone else's code that calls tools like git or jj with an optional pager, assuming the pager is disabled, it's a pain having to turn the pager option on and off every time I use their code.

At least git will page if stdout is a terminal but not otherwise.

When you say you have to "turn the pager option on and off every time I use their code", can you give some example?

Can you give a concrete example where this doesn't just magically work?

[walles]

Can you ask your LLM to call git with --no-pager? Does that help?

git --no-pager status

[walles]

Or maybe try PAGER=cat external-tool.sh?

[kseistrup]

Setting cat as pager does dump the rendered document to standard output. However, since moor will try $VISUAL first, that environment variable is more suitable: https://github.com/walles/moor/blob/master/internal/editor.go#L74

[walles]

since moor will try $VISUAL first, that environment variable is more suitable

I agree that setting $VISUAL rather than (or in combination with) setting $PAGER might be required, thanks for clarifying!

However, as a technical detail, when you set these variables and that makes external-tool.sh print to stdout, it's because external-tool.sh launched cat instead of moor, and what's in moor's source code won't matter in this case.