Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show header/grid even for empty files? #563

Closed
kbd opened this issue May 12, 2019 · 8 comments · Fixed by #566
Closed

Show header/grid even for empty files? #563

kbd opened this issue May 12, 2019 · 8 comments · Fixed by #566
Labels
bug Something isn't working

Comments

@kbd
Copy link
Contributor

kbd commented May 12, 2019

Because bat helpfully prints out a header for every file, I never again have to do things like:

for file in *.txt; do echo "\nFile: $file\n"; \cat "$file"; done

when I cat multiple files to know what text goes with what file. Now I can straight fd ... | xargs bat, and this makes me happy.

There's one difference though from that shell loop above: you don't get any output for empty files. I get how bat evolved that way; cat gives no output for empty files so bat does the same. With bat, the chrome could be useful by itself even for empty files. It would be nice if there was a flag to enable printing empty files.

@sharkdp
Copy link
Owner

sharkdp commented May 12, 2019

Thank you for the feedback.

What exactly do you expect? bat does print headers for empty files as well:

▶ printf "" > empty
▶ printf "hello" > a-non-empty
▶ printf "hello" > z-non-empty
▶ bat *
───────┬─────────────────────────────────────────────────────────
       │ File: a-non-empty
───────┼─────────────────────────────────────────────────────────
   1   │ hello
───────┴─────────────────────────────────────────────────────────
───────┬─────────────────────────────────────────────────────────
       │ File: empty
───────┼─────────────────────────────────────────────────────────
───────┴─────────────────────────────────────────────────────────
───────┬─────────────────────────────────────────────────────────
       │ File: z-non-empty
───────┼─────────────────────────────────────────────────────────
   1   │ hello
───────┴─────────────────────────────────────────────────────────

PS: When combining bat with fd, you can use fd's new -X (capital -X) option to save a few keystrokes:

fd … -X bat

@kbd
Copy link
Contributor Author

kbd commented May 12, 2019

bat does print headers for empty files as well

Wow, that's not what mine does:

$ ls
$ printf "" > empty
$ printf "hello" > a-non-empty
$ printf "hello" > z-non-empty
$ bat *
───────┬─────────────────────────────
       │ File: a-non-empty
───────┼─────────────────────────────
   1   │ hello
───────┴─────────────────────────────
───────┬─────────────────────────────
       │ File: z-non-empty
───────┼─────────────────────────────
   1   │ hello
───────┴─────────────────────────────
$ bat --version
bat 0.10.0
$ ll
total 8
-rw-r--r-- 1 kbd staff 5 May 12 16:17 a-non-empty
-rw-r--r-- 1 kbd staff 0 May 12 16:17 empty
-rw-r--r-- 1 kbd staff 5 May 12 16:17 z-non-empty

Any idea why mine would be different?

you can use fd's new -X

Thanks, I saw that, but it uses a randomized order like you'd get with -x. Piping to xargs, on the other hand, processes files in the order of fd's output. I actually almost opened up a bug report on fd about this earlier, that I'd have expected -X (while not -x) to behave more like xargs and pass arguments in order, but I figured it was expected behavior and I'd be wasting your time. But since you funnily brought it up I figured I'd explain that there's still a difference that made me use xargs.

$ for i in a b c d; do echo $i > $i.txt; done
$ fd
a.txt
b.txt
c.txt
d.txt
$ fd -x bat
c
b
d
a
$ fd -X bat -p
c
b
a
d
$ fd | xargs bat -p
a
b
c
d
$ fd --version
fd 7.3.0

@sharkdp
Copy link
Owner

sharkdp commented May 13, 2019

Ah, sorry. I was testing with master instead of v0.10.0. I completely forgot that this was a problem that was fixed recently, see #500 and #504.

I should definitely release a new version soon 😄

@sharkdp sharkdp added duplicate This issue or pull request already exists bug Something isn't working and removed duplicate This issue or pull request already exists labels May 13, 2019
@kbd
Copy link
Contributor Author

kbd commented May 13, 2019

this was a problem that was fixed recently

Sweet! Glad to hear. That's the best kind of problem (one that's already fixed).

One thing I noticed, in your version above, an empty file looks like:

───────┬─────────────────────────────────────────────────────────
       │ File: empty
───────┼─────────────────────────────────────────────────────────
───────┴─────────────────────────────────────────────────────────

In #500 you show the empty file display like this:

───────┬───────────────────────────────────────────
       │ File: empty.txt
───────┴───────────────────────────────────────────

Just my 2¢: I like the second variation better. It cuts down on clutter + needless separators for empty files.

One small suggestion: just like you have a header for a few things, like <BINARY> or encodings:

$ bat utf16.txt
───────┬────────────────────────────────────────
       │ File: utf16.txt   <UTF-16LE>
───────┼────────────────────────────────────────
   1   │ <U+FEFF>This is text in UTF-16
───────┴────────────────────────────────────────

It might be nice to add something there like <EMPTY> or <0 bytes> in the header for an empty file.

Lastly, any comment on that fd -X issue? Is that intended behavior or should it be expected to match xargs? (I'll create an issue there if you'd like.)

@sharkdp
Copy link
Owner

sharkdp commented May 13, 2019

you can use fd's new -X

Thanks, I saw that, but it uses a randomized order like you'd get with -x. Piping to xargs, on the other hand, processes files in the order of fd's output.

Note that due to parallelism, fd's output order is actually not deterministic (even if it often looks like it actually is, especially in small examples). This means that you can not "predict" the execution order by first running fd … and then running fd … | xargs ….

I actually almost opened up a bug report on fd about this earlier, that I'd have expected -X (while not -x) to behave more like xargs and pass arguments in order, but I figured it was expected behavior and I'd be wasting your time.

Unfortunately, execution mode (-x/--exec) works a little bit different than normal search mode. This is why the "seemingly deterministic" output order does not show up when using execution mode.

To be honest, I'm a little surprised myself that batch execution mode (-X/--exec-batch) has such a different behavior than using fd … | xargs and it might make sense to open a issue in fds repo for that.

But in general, you can never rely on any (output or execution) order when using fd.

@sharkdp
Copy link
Owner

sharkdp commented May 13, 2019

Just my 2¢: I like the second variation better. It cuts down on clutter + needless separators for empty files.

Oh, you are absolutely right. I missed that in the linked ticket. We should try to get the old behavior back (second variation). I also like that better.

It might be nice to add something there like <EMPTY> or <0 bytes> in the header for an empty file.

👍

@kbd
Copy link
Contributor Author

kbd commented May 13, 2019

Yeah your fd docs are clear that -x execution is parallelized so even if fd's normal output order were deterministic I wouldn't expect -x's to be. For -X I thought "oh, so that's like xargs", and was surprised when it wasn't. I'll open a ticket on fd.

@sharkdp
Copy link
Owner

sharkdp commented May 15, 2019

Fixed in v0.11.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants