271–280 of 280 posts
bat is cool but is there a way to get not to dump everything into my terminal and just page just like less? i wonder if there's a `bless` ?
Earlier quoted context omitted.
Well there's the portability of grep which is better for scripts. Besides that, most if not all times I do a simple `ag pattern file`, I'm interested only in the results and not in the location. I'm probably preparing the pattern to output something to provide to another command via stdin or substitution and at those times (which is also in the interactive command line), I want to see exactly what I'm going to pass i…
> It seems you also chose to output line numbers by default in that case, but it's nice that you have -N. Right. When you run ripgrep with its output connected to a tty, then its output is "prettified." That means results are grouped by file, colorized and include line numbers. But if you aren't connected to a tty, then ripgrep reverts to the standard grep format (e.g., no line numbers). This means you should be able…
Yes, I knew that. What I meant to say is that in the particular case of "rg pattern file", I feel it doesn't to the right thing. I understand that my usual usage of that kind of invocation may not be like the majority, so I understand that other people might prefer that default as it is right now. In my usual usage, though, I feel the numbers are burdensome, because I have to imagine the output without it to know what I'm passing in to the next command I've yet to type in the pipeline. I can't remember the last time I used that kind of invocation to look for the line number a match was in. I only ever use the line numbers when matching a directory or multiple files.
> Yes. That's the -M/--max-columns option. I have that set by default in my config:
That's awesome, and thanks for sharing your config.
Earlier quoted context omitted.
Plain text was chosen to interface the various programs of Unix OSes because it's the least common denominator all languages share. It also forces all tools to be composable with each other. You can take output text that was obviously not formatted for easy consumption by another program and still use all the information it outputs for input into another program. Programs that were only thought to have users handling…
How hard is it to come up with a object format (more like a data structure format since I wouldn't want logic/code being passed around) and then come up with a standard text serializer for it? Not that hard, in my opinion. You'd standardize it once via an RFC and you'd be done with it. I don't think your problem is as big as you say it is. The real problem is that this pile of code we already have kind of works and i…
Are TUIs like htop, tmux, vim, emacs, less, etc. going to be impossible now, or will you do the negotiation protocol? Both options suck.
When programs have both normal output and errors intermixed are the objects going to be intermixed in the output that's presented to the user? For example, if you do a `find /etc/pacman.d`, instead of:
/etc/pacman.d
/etc/pacman.d/mirrorlist.pacnew
/etc/pacman.d/gnupg
/etc/pacman.d/gnupg/trustdb.gpg
/etc/pacman.d/gnupg/crls.d
find: ‘/etc/pacman.d/gnupg/crls.d’: Permission denied
/etc/pacman.d/gnupg/.gpg-v21-migrated
/etc/pacman.d/gnupg/private-keys-v1.d
find: ‘/etc/pacman.d/gnupg/private-keys-v1.d’: Permission denied
/etc/pacman.d/gnupg/tofu.db
/etc/pacman.d/gnupg/openpgp-revocs.d
find: ‘/etc/pacman.d/gnupg/openpgp-revocs.d’: Permission denied
/etc/pacman.d/gnupg/gpg.conf
/etc/pacman.d/gnupg/secring.gpg
/etc/pacman.d/gnupg/pubring.gpg~
/etc/pacman.d/gnupg/pubring.gpg
/etc/pacman.d/mirrorlist
[
"/etc/pacman.d",
"/etc/pacman.d/mirrorlist.pacnew",
"/etc/pacman.d/gnupg",
"/etc/pacman.d/gnupg/trustdb.gpg",
"/etc/pacman.d/gnupg/crls.d",
[
{
type: "Permission denied",
path: "/etc/pacman.d/gnupg/crls.d"
},
"/etc/pacman.d/gnupg/.gpg-v21-migrated",
"/etc/pacman.d/gnupg/private-keys-v1.d",
{
type: "Permission denied",
path: "/etc/pacman.d/gnupg/private-keys-v1.d"
},
"/etc/pacman.d/gnupg/tofu.db",
"/etc/pacman.d/gnupg/openpgp-revocs.d",
{
type: "Permission denied",
path: "/etc/pacman.d/gnupg/openpgp-revocs.d"
},
"/etc/pacman.d/gnupg/gpg.conf",
"/etc/pacman.d/gnupg/secring.gpg",
"/etc/pacman.d/gnupg/pubring.gpg~",
"/etc/pacman.d/gnupg/pubring.gpg",
"/etc/pacman.d/mirrorlist",
]
]
You could have every function incorporate their errors into their normal output, but that means giving up a standardized way of working with errors and warnings. I don't know if you know this, but when you do substitution or piping, by default, only stdout is used. That means that we you do piping, the programs in the pipelines normally do not see the errors in their inputs, and the errors of the multiple concurrently running programs are shown to you intermixed while the pipeline is working. That's a friggin' incredible effect that came from simple design, but when each one would output objects, you'll could get syntax errors or a completely different object like what happened in the above example. You could say, "well, only make stdout an object and let stderr be text," but the fact that they're both the same type means that you can work with the error or only with your errors in pipelines and other shell constructions. For example, `find /etc 2>&1 >/dev/null` will output the directories in /etc you can't read for whatever reason. You might want to pipe that to `xargs chmod` (for whatever reason) after preparing the output to only include the paths.
Right now, programs can strike a good balance in presenting its output in a format that is both readable to humans and other programs. By forcing their output to be structured as objects, and not giving them the option of presenting 2 formats (because we don't want that either), you're removing their ability to present the output in a manner that is readable to humans.
Take for example, rspec's output (a unit testing framework):
$ rspec spec/calculator_spec.rb
F
Failures:
1) Calculator#add returns the sum of its arguments
Failure/Error: expect(Calculator.new.add(1, 2)).to eq(3)
expected: 3
got: nil
(compared using ==)
# ./spec/calcalator_spec.rb:6:in `block (3 levels) in '
Finished in 0.00131 seconds (files took 0.10968 seconds to load)
1 example, 1 failure
Failed examples:
rspec ./spec/calcalator_spec.rb:5 # Calculator#add returns the sum of its arguments
The main thing is, though, that, in the question of what the universal format of communication between programs written in different languages should be, text is the simpler, more natural choice over objects. Take note, I don't mean easier. The fact that it's easier is merely coincidence. Simplicity leads to good design because it means less arbitrary choices to make. Less controversial choices to make. Choosing objects leads to more questions: What should the primary types be? Should arrays/lists allow multiple types of elements? Floating types or decimals? Precision restriction on the decimals? Should integers and numbers that allow fractional parts be the same type or different? Should we have a null type? Should we have a date primary type? What about a time primary type? What about a datetime primary type? Whatever answers you give, there will always be groups of people that will dislike them. When you chose text, the only question is really, what encoding? Utf-8. done. Natural, simple design is what we want to be the foundation that myriads of programs and languages can base themselves on and depend on.
There's only one way I'd agree with you that structured output would be nice, and that's with mono-language OSes, like a lisp OS or some other OS where all code is in the same language, and there would be no concept of programs or shared / dynamically loaded libraries or such. In an OS like that, every function is a program, and your shell is the language's REPL. This is bliss when the OS is done in your favorite language. The problem with these kinds of OSes is that we don't all like the same languages and so it'd lead to ridiculous situations where we'd translate a new language into the high level language of the OS. That's what we do in the OS known as the web browser and why we're coming up with WebAssembly.
In conclusion, multi-language OSes like those that are Unix based are awesome, and text as the basis of communication in multi-language OSes is awesome. Therefore, text as the basis of communication in Unix is awesome. :)
Earlier quoted context omitted.
It's not about backwards compatibility. It's about the fact that text is what we read as humans and if commands parse the same format there is only one output format to implement.
I don't believe that. Text for human consumption, in a well designed UI (and I mean even a CLI one!), should be different from text for machine consumption. Human consumption generally optimizes for characteristics almost diametrically opposed from machine consumption. Of course, who am I kidding, in real life we have some sort of crappy text interface which is half-baked both for humans and for machines. But we've b…
1) We don't need to depend on each individual program's programmer to present every control and information consistently between the 2 interfaces.
2) Automation matches normal, manual use. Just put what you normally do on the command line in a file and you're done. There's no need to look through documentation on how to do what you so frequently do, only in a manner that you rarely do.
> There is a weird bug in Mac Sierra that can be overcome by running htop as root I don't think this was a bug; I think the issue was that htop uses needed something in task_for_pid that required root.
Oh this was definitely a bug already, and a nasty one at that, as it froze the whole computer in a few minutes while the kernel was racing against itself and starving for some resource (which didn't happen while being run as root). It was fixed in macOS 10.13.4 / htop 2.2.0 https://github.com/hishamhm/htop/commit/b2771218 https://github.com/hishamhm/htop/issues/682
Earlier quoted context omitted.
I disagree about objects being preferable to text in a shell. Text is very easy to reason about, and you can quickly determine what transformations you need to make based on visual feedback. Working with objects means spending a lot more time in the documentation learning what properties you have to work with. In a programming language, it's obviously no context. But in a shell, I want to spend more time doing and le…
> Text is very easy to reason about, and you can quickly determine what transformations you need to make based on visual feedback. Working with objects means spending a lot more time in the documentation learning what properties you have to work with. Or not. Take `ps`. You'll need to spend time in documentation anyway, figuring out what process properties can be shown with what flag, and then you'll be bitten later…
Powershell is too complex to be a good shell, and there are too many bizarre idiosyncrasies about it to hold its own as a programming language. It just doesn't really have a place.
Earlier quoted context omitted.
> Text is very easy to reason about, and you can quickly determine what transformations you need to make based on visual feedback. Working with objects means spending a lot more time in the documentation learning what properties you have to work with. Or not. Take `ps`. You'll need to spend time in documentation anyway, figuring out what process properties can be shown with what flag, and then you'll be bitten later…
A shell is supposed to be an interactive user interface and a very thin glue layer for some simple tasks. Once you move beyond a certain level of complexity, a shell is just the wrong tool for the job. Powershell is too complex to be a good shell, and there are too many bizarre idiosyncrasies about it to hold its own as a programming language. It just doesn't really have a place.