So, I was excited by the idea of a terminal that added new functionality and wasn't electron based. So I downloaded Warp.
And, honestly, I can't use it. They interfere with the operation of the shell to such a degree that I had to disable almost my entire bash configuration.
Add to that, that I already have the following features native to bash shell (and I'm sure they're in zsh too):
- history of commands: easily searched by pressing ↑ or ⌃+r
- completion: via the awesome bash-completion project
- split panes: both terminal.app and screen do this for me
- session sharing: screen + ssh does this for me
- "workflow" sharing, I can and do write shell scripts that can be used by others
I've seen comments trying to defend this that REALLY make me doubt that the devs even understand how a terminal + shell work. A shell script will run in it's interpreter regardless of what shell you happen to use, shared commands will inherently be in the flavour of shell-script that the sharer is used to, and so i have to know how to use their shell as well as mine to translate between them, which again isn't a problem when running a script. They claim that people don't document their scripts, but the same people who won't document a script won't document stuff they share in warp. They claim there's no way to find documentation natively from the terminal or to search for scripts based on what they do, apparently they haven't heard of apropos and man pages?
Warp engineer here! The shell has arbitrary access to the environment, and there's a long tail of shell config to play nice with. For example, here's a fun technical read about how we supported PS1 and how the 9c byte caused some issues (https://www.warp.dev/blog/whats-so-special-about-ps1). We've prioritized issues based on the impact for the product. If you're up for it, I'd love if you could file some issues about the problems you're experiencing.
There are a lot of great shell configs. One advantage of Warp is that the terminal & shell have these features out-of-the-box.
> A shell script will run in it's interpreter regardless of what shell you happen to use, shared commands will inherently be in the flavour of shell-script that the sharer is used to, and so i have to know how to use their shell as well as mine to translate between them, which again isn't a problem when running a script.
Workflows in Warp specify the shell in the metadata.
The idea for workflows is to allow people to search commands based on what they accomplish, rather than requiring everybody to remember the command and type. For example, if I wanted to delete all empty files in a line, instead of remembering the exact incantation of sed to accomplish this, I could search "delete empty files".
> For example, if I wanted to delete all empty files in a line, instead of remembering the exact incantation of sed to accomplish this, I could search "delete empty files".
(I'm assuming you meant "delete all empty lines in a file", since "delete all empty files in a line" doesn't make sense)
You don't need "the exact incantation of sed"; it can be done in 6 bytes: `grep .` if you know a bit of basic coreutils-fu. And if you want to do it with sed, which also allows you to do it in-place, it's not an "incantation" either. `sed -i /^$/d`. I didn't know that command ahead of time, I just worked it out using my problem solving skills and basic knowledge of sed. If you think it's an unintelligible incantation that you have to remember and can't reconstruct yourself, then you're not much of a developer.
Why would a developer want to search for "delete empty lines" in their terminal? If you don't know how to do it, you'd Google it and copy-paste from StackOverflow. If you do know how to do it, you'd just do it without needing to search for anything. It's not a complicated task.
And if it is a more complicated or at least a less general task, then a developer is gonna be able to write a program to do it.
Maybe your point is that someone else has already done that, but in which case, again, there's Google, or company documentation, or you can ask your colleague, or look in the `project/tools/` for the name of the script that does it already.
And, honestly, I can't use it. They interfere with the operation of the shell to such a degree that I had to disable almost my entire bash configuration.
Add to that, that I already have the following features native to bash shell (and I'm sure they're in zsh too):
- history of commands: easily searched by pressing ↑ or ⌃+r - completion: via the awesome bash-completion project - split panes: both terminal.app and screen do this for me - session sharing: screen + ssh does this for me - "workflow" sharing, I can and do write shell scripts that can be used by others
I've seen comments trying to defend this that REALLY make me doubt that the devs even understand how a terminal + shell work. A shell script will run in it's interpreter regardless of what shell you happen to use, shared commands will inherently be in the flavour of shell-script that the sharer is used to, and so i have to know how to use their shell as well as mine to translate between them, which again isn't a problem when running a script. They claim that people don't document their scripts, but the same people who won't document a script won't document stuff they share in warp. They claim there's no way to find documentation natively from the terminal or to search for scripts based on what they do, apparently they haven't heard of apropos and man pages?