akavel / up Goto Github PK

please allow giving command to up as parameter (also to avoid the rm nightmare)

Write/copy it based on readme + update with features added in subsequent releases.

Hi! I made a quick snap package for up, so that I could easily install/update the program on ubuntu.
It is classic (not confined) so it has access to the system as a normal program.
Are you interested in supporting this? If not can I publish it on the snap store (with a note saying it is unofficial)?

I tried to do some pipelining for comparison.
But when I tried to paste the content of my clipboard to this tools command prompt, only the first 11 characters got copied to it.

Here's the screencast in case needed.

Including the ability to tab complete would make this tool truly perfect.

Great job either way, love this idea!

Love what you've done!

I wrote something similar (but not the same) a while back. https://github.com/sebglazebrook/infinite-pipe

I think stuff like this is super useful and really changed the way you approach comma d line usage.

So cool!

Great tool! I have a non-critical feature request: It would be nice if up supported color codes such as those output by grep --color=always.
Thanks!

Every time return is hit, a copy of the pipeline is pushed to the history, allowing the user to go back to older version.

This lets one work on different parts, in different ways before getting to the final result

Would it be possible to add a checksum.txt for release artifacts going forward? Its nice to be able to verify the builds for extra piece of mind. An example would be something like fabio: https://github.com/fabiolb/fabio/releases

Hello, I'm a designer and I want to know if I can create a logo for your project

Hi, I am new to up and encountered an issue while using it.
When the file is in Chinese, the characters are not displayed normally in the program

$ cat 1.txt
吃饭
喝茶
睡觉

Inside up, it showed only one character

cat 1.txt | up 
 |
吃
喝
睡

And grep cannot work well either.

Given that it works on a mac #6, perhaps it can be submitted to homebrew so installation is super easy on a mac with:

brew install up

where is?

I like to run up to just run grep searches interactively (using ripgrep on the current directory).

I use NixOS which does not have a /bin/bash, it only has /bin/sh. Would that work instead?

Someone already created a PKGBUILD for up so it's just a matter of yaourt -Syy up to install Ultimate Plumber on Arch/Manjaro systems. Thanks a bunch!

Hi there,

Our team at GPU Exchange uses this tool a lot and we want to give back to the project.

We sketched together some logo ideas for this (see below). Let us know which one you like most and I'll send over the source file for your future branding use.

Thanks again,

FZF and Navi have the concept of shell widgets, they can take over your prompt and then when you're done leave you with the text you wanted filled-in to your prompt.

I think Navi's shell widget is a good example of what I'm talking about (see navi widget zsh, for instance). You can press ctrl-g, fill in a template, and when you're done your prompt is pre-populated with the command you selected and filled in. If you already have stuff filled in when you press ctrl-g then Navi takes that into account and starts a search for you.

It would be cool to, for instance, press ctrl-u with some command already filled in and have up take over at that point. Once done, exiting up would leave the prompt pre-filled with the final pipeline.

Environment:

• macOS High Sierra (v10.13.6) - Darwin 17.7.0
• Go 1.11.1

Download & Compile

go get -u github.com/akavel/up

Test

man man |& up

Output

A mode to compare the difference between the output of two files.

Like:

$ diff <(cat file1.txt |& ./up) <(cat file2.txt |& ./up)

It will be very useful to compare two different log of a process. For instance, looking for a bug comparing the correct and the incorrect log output.

I feel like it would make sense for up filename to be a valid invocation, with it having the same effect as cat filename | up.

The new press-enter-to-run mode makes up a lot safer, but it would still be nice to have something like the old mode. Maybe a new mode where the command is automatically run, but only after a configurable amount of time without any input?

Probably still shouldn't be the default, but it would be a nice in-between option.

(Would happily dive in and make a PR to implement this, if you're interested!)

Didn't work for me when I tried up on MacOS. Need to try if it works on Linux or not, then need to make it work.

It the terminal (with readline for example, Ctrl-W erase the command until finding a space, which is very practical and is missing in up.

A lot of posters are rightly worried about the safety risks. Why not just run the pipeline as a nobody user? Pipelines should be textual manipulations by default, so they don’t need any filesystem permissions.

For extra security, you could unshare networking to avoid accidental network access, although that seems less likely to occur entirely by accident.

I'm not sure if this is the right place to ask. But tailing & using the grep filter on the fly would be super usefull.

Feel free to close the issue if out of place.

This is not an issue per se, but I wrote a small zsh function to integrate up:

zle-upify() {
    buf="$(echo "$BUFFER" | sed 's/[ |]*$//')"
    tmp="$(mktemp)"
    eval "$buf |& up --unsafe-full-throttle -o '$tmp' 2>/dev/null"
    cmd="$(tail -n +2 "$tmp")"
    rm -f "$tmp"
    BUFFER="$BUFFER | $cmd"
    zle end-of-line
}
zle -N zle-upify

bindkey '^U' zle-upify

If you add this to your zshrc, Ctrl+U will run up passing the current commands output, and when you exit up with Ctrl+X, the result will replace current prompt. It's slightly easier than dealing with upN.sh files.

It was quite useful for me, I'm just sharing this so maybe you'd like to put it to README.md or somewhere people can find out.

It would be great if up would support my Readline movement commands.

https://www.gnu.org/software/bash/manual/html_node/Bindable-Readline-Commands.html

Thanks.

With short licensing info for all dependency libraries.

At the risk of ignoring tongue in cheekiness; this warning seems too buried. Also there is a world of difference between "being careful using rm or dd" vs having a simple typo immediately be run as a command vs having to type something fully before hitting enter. I understand the impulse of closing this loop of iterate and see results; doing it this way though seems beyond dangerous.

WARNING: Please be careful when using it! It could be dangerous. In particular, writing "rm" or "dd" 
into it could be like running around with a chainsaw. But you'd be careful writing "rm" anywhere in 
Linux anyway, no? Also, why would you want to pipe something into "rm"? Other than that, I don't 
really have good ideas how to protect against cases like this. And in the other, non-dangerous 
cases, I find the tool immensely useful. If you have some ideas how to try to protect, please share! 
That said, a tool wouldn't be really Unixy if you couldn't hurt yourself with it, right? ;P

https://godoc.org/github.com/gdamore/tcell#SimulationScreen

This looks like a very useful tool, but I won't use it on my system as long as it automatically executes incomplete commands as they're being typed.

It shouldn't execute a command until it's explicitly told to do so. Hitting the TAB key might be one reasonable way to do that.

You're on Hacker News this morning: `https://news.ycombinator.com/item?id=26644110

Regarding safety issues users on HN have suggested using ptrace to intercept syscalls to simulate commands like "rm" and "dd". This seems like it might lead to some frustrating edge cases, though. Especially if you're trying to support MacOS and Linux.

https://news.ycombinator.com/item?id=26644508

Another user suggested using the seccomp syscall in Linux, pledge in BSD to disallow writes from the UP process.

https://news.ycombinator.com/item?id=26644319

Finally another user suggested using blacklists/whitelists to disallow certain destructive executables.

https://news.ycombinator.com/item?id=26644442

I think all three of these are good ideas with varying levels of complexity. It would protect users who don't realize that this tool can be destructive (or those of us who are absentminded) and perhaps make it possible to use a live search mode again.

I feel like a lot of us could be more comfortable using this if we could set a regex or some other way of preventing the program from previewing commands that might be destructive (rm, dd, shutdown, etc).

It would be great to allow to change colors. My terminal color scheme displays up command line in low contrast.

There are two missing pieces in up:

• Persistent shell: Currently up forks a new shell for each command. This is very inefficient (especially if you have a lot of shell functions and heavy dotfiles like I do), and also doesn't persist variables. Solving this one alone is not very hard; I have a library for Python for using a persistent shell, and a similar thing should be easily implementable here. We just need a socket (I currently use stdin/stdout for brish, but I plan to change this to proper sockets) to communicate between the interpreter and the host, and a helper server written in the interpreted shell that reads the commands the host sends and sends their results back.

• Autocompletion: Getting this to work is harder. I know of this zsh plugin that does this for zsh, but my experience of it has been slow, and buggy and it doesn't return all the completions. However, I think that if we can get the shell to run in an emulated terminal thingy, we should be able to use the shell's builtin autocomplete and also get it to persist at the same time. Now, that linked plugin is kinda doing this as well, though I haven't looked at it too deeply and anyways I don't know these gritty low-level details at all. The idea I have is using tmux. Solving the first problem with tmux should be easy (we can send the needed keystrokes to tmux. Its shell API is tmux send-keys ....), however, reading the results and also capturing completions triggered by pressing tab is harder. But I think this is the most promising avenue, and it works with any interpreter.

TCell seems to need to recognise the value of $TERM. There's an issue over at the TCell repo, but it's pretty old. This means that up won't work for many people using less-popular terminals (Kitty for me).

A workaround at the moment is to alias:

$ alias up="TERM=xterm up "

Is there some way to bypass this from the up side?

While typing a command, when I'm in the middle, of course it's going to fail while I'm still writing it because it's not complete. In addition to showing the error from the command in progress, it would be great to also show the result of the previous command so I can remember what the output looks like. Cool tool though :)

given: very_large | filter_1 | filter_2 | filter_3 | filter_4

if the cursor is in the filter_2, only run: very_large | filter_1 | filter_2

why? when writing a series of filter it happens that after writing filter_4 the results contain data that one thought would be filtered/transformed by filter_1. It is of course possible possible to add another filter but maybe not logical. when changing filter_1, a view of the output would be very helpful but that's not possible without deleting the pipeline.

Hello.

Just discovered the tool and overjoyed about it.
However, being one prone to kilometre-long pipelines (which clutter my history with all the trial and errors, hence why I love the tool even more) the input line seems awfully short, in general, given how input lines longer than the screen width just go beyond the visible area, with no horizontal scrolling or line-wrapping allowing to see what one is writing.

Could you do something about that?

Thanks a bunch!