grep does have `--color=auto`, though, which checks whether you're printing to a terminal or not.
exa's opinion is this: users shouldn't be expected to know that adding colour to ANSI terminal output adds more bytes to the stream. If you run `foo`, see that it outputs a line, then run `foo | grep line`, you'd expect to see that line without having to stop and think about what representation the colours had.
Yeah, it's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes. There's just no way for exa to know that it's being piped into less while keeping the above rule true too.
> it's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes.
I'm not certain if it's exactly what you're getting at, but less can be instructed to parse ANSI color sequences, and output them, with the -R flag. (If you forget to put -R on the command line, or some utility automatically starts less for you, you can also type "-R" while in less to trigger that behavior.) That said, less has to be fed the sequences, and most programs will not output color sequences when piped to less, as they detect that the output isn't a TTY (this is normally the right thing to do, it just kinda sucks in less's case) so you might need to, e.g., that_prog --color=always | less.
> There's just no way for exa to know that it's being piped into less while keeping the above rule true too.
Yeah, this is the real problem. I kind of wish there was some sort of content negotiation between piped utilities, s.t. less could inform the upstream utility of "hey! I speak ANSI color codes!".
What follows is definitely well into the "WTF too clever" column and I do not recommend it, but, this is HN: I presume you could riff through /proc trying to find the other end of the pipe that you're writing to (I think /proc on Linux has that) and then, if the executable's name is "less", well, you see where I'm going…
That's where you need something like PowerShell, which pipes objects around instead of streams of bytes which are probably text.
Of course, PowerShell has its own issues, but the idea of a shell with more meaning attached to things is appealing. Rebuilding an ecosystem that can handle it all though... not so plausible!
> and I would add that the community provided recipes aren't very good either.
This is key. When I first got into using Chef, I assumed things would be no problem because all the services I used already had community recipes.
The community recipes are often wrong, don't work correctly on "clean" first-time installs and have a lot of baked in assumptions about the config and modules to use.
Clone these recipes into your repo, you will be modifying them. Blindly relying on the built in functionality to pull in and update the community repos will lead to pain.
Chef is a powerful tool, but it is also evolving rapidly and requires careful attention and testing.
I've found that using the "Nimbus" look and feel (Settings -> IDE Settings -> Appearance) and making sure "Use anti-aliased font" is checked (Settings -> IDE Settings -> Editor -> Appearance) do pretty well.
I am using an Oracle 1.6 Java on Ubuntu 10.10.
PyCharm and IntelliJ also seem to default to an "Alloy" look and feel on Windows, but changing that to the native Windows L&F vastly improves both the fonts and general appearance.
I really like Dropbox - the ubiquity and ease of use are great.
There's one annoying hangup tho, and this is what so far has kept me from paying for a great service I would otherwise immediately sign up for a paid account:
When you share a file/folder in your Dropbox with someone the space used counts against BOTH your quota AND the other person's quota.
This means that even if I am paying $10/month for a 50GB account, if I share a folder that has 2GB of data with a coworker or friend that only has a free account, that share immediately fills their entire quota.
Dropbox's only answer to this problem is that you should sign up for "Dropbox for teams." This is $795/year for 5 users with a shared quota. Not really an acceptable solution in my opinion.
On the other hand, if sharing didn't count towards both parties' quotas, then you could just create an army of sockpuppets, each of whom shares their 2GB folders with you. I understand that the Dropbox people don't want to make it that easy.
- You can do anything at zombo com