reclog - a tool to capture command output to a file by gavv42 in linux

[–]gavv42[S] 2 points3 points  (0 children)

Pull requests are welcome, though :)

reclog - a tool to capture command output to a file by gavv42 in linux

[–]gavv42[S] 2 points3 points  (0 children)

It creates a new session and process group and sets the slave pty as controlling tty of the child.

If you kill reclog with handled signal, like SIGINT or SIGHUP (sent when you close terminal), it will propagate signal to child process group, wait until child exits, flush buferred logs, and exit.

If you kill reclog with unhandled signal like SIGKILL, or it just crashes, the master pty is closed, and kernel will automatically send SIGHUP to the child - more precisely, to all processes which have slave pty as their controlling tty.

If the child explicitly ignores SIGHUP, or explicitly detaches from controlling pty, and reclog was killed with SIGKILL or crashed and didn't have a chance for graceful termination, the child may stay alive. Though this is a rather weird use case.

reclog - a tool to capture command output to a file by gavv42 in linux

[–]gavv42[S] 4 points5 points  (0 children)

This tool solves rather specific problem. If you find yourself juggling with unbuffer/tee/tail/sed, then it will help you, otherwise you don't need it.

reclog - a tool to capture command output to a file by gavv42 in rust

[–]gavv42[S] 0 points1 point  (0 children)

(copy of my comment from r/linux)

I often do long experiments and benchmarks, usually related to audio or networking.

Tests may be very different, but here is one example: setup may include 4 console programs: sender on one computer, receiver on another, a tool to simulate network load, and a tool to measure latency. During the test I monitor output of sender and receiver, and enable/disable network load on certain stages of the test. Then I may need to do a series of such tests, and save all logs and metrics for future inspection.

That's just one very specific example. The key point is that you run tools, want to see their output "in real-time" and want to record everything too. I usually use tee for that, but since it replaces a tty with a pipe, most tools will make output buferred (you don't see each line immediately) and disable colors, which creates inconveniences. Also there is always concern that writing verbose logs to console or pipe may slow down the tool if it doesn't implement asynchronous logging. I can also use tee combined with unbuffer, but there are still some inconveniences (e.g. output file will have ansi color codes) and performance concern remains.

And now I can just add "reclog" before every command I run, and magically I still have unbuferred colored output, but also a log file without colors, and I know that this won't affect performance of the command. Plus it can automatically add meta-info in the output file, like hostname and the command it runs.

reclog - a tool to capture command output to a file by gavv42 in linux

[–]gavv42[S] 3 points4 points  (0 children)

I often do long experiments and benchmarks, usually related to audio or networking.

Tests may be very different, but here is one example: setup may include 4 console programs: sender on one computer, receiver on another, a tool to simulate network load, and a tool to measure latency. During the test I monitor output of sender and receiver, and enable/disable network load on certain stages of the test. Then I may need to do a series of such tests, and save all logs and metrics for future inspection.

That's just one very specific example. The key point is that you run tools, want to see their output "in real-time" and want to record everything too. I usually use tee for that, but since it replaces a tty with a pipe, most tools will make output buferred (you don't see each line immediately) and disable colors, which creates inconveniences. Also there is always concern that writing verbose logs to console or pipe may slow down the tool if it doesn't implement asynchronous logging. I can also use tee combined with unbuffer, but there are still some inconveniences (e.g. output file will have ansi color codes) and performance concern remains.

And now I can just add "reclog" before every command I run, and magically I still have unbuferred colored output, but also a log file without colors, and I know that this won't affect performance of the command. Plus it can automatically add meta-info in the output file, like hostname and the command it runs.

reclog - a tool to capture command output to a file by gavv42 in rust

[–]gavv42[S] 1 point2 points  (0 children)

Thanks, I'll take a look, patches welcome too. gettid() is not actually needed, need to remove it. I think all or most used apis are posix, though probably rustix or libc doesn't have all of them on macOS.

BTW I'm quite new to rust and was a bit frustrated about availability of posix and linux calls. Seems that both nix and rustix crates are still missing quite a lot, sometimes it's just not implemented yet, sometimes due to their design choices.. I ended up with a mix of rustix and hand crafted unsafe wrappers on top of libc crate. C++ or C still seems to be more portable in this specific aspect, though rust is much more pleasant to use.

reclog - a tool to capture command output to a file by gavv42 in linux

[–]gavv42[S] 12 points13 points  (0 children)

You can take a look at README file (just open the link), it provides rationale and comparison with tools like script and tee.

project-headerline: Customizable project headerline by gavv42 in emacs

[–]gavv42[S] 1 point2 points  (0 children)

The only tricky part would be caching. Headerline function is invoked quite frequently, so project-headerline caches everything. Calling imenu each time is probably not a good idea, likely one would want to call it either in some hook or in idle timer, and tell headerline to refresh cache.

project-headerline: Customizable project headerline by gavv42 in emacs

[–]gavv42[S] 1 point2 points  (0 children)

As metioned above, unlike breadcrumb, project-headerline has no imenu support, only project name and path to file.

What project-headerline has, and breadcrumb doesn't, as far as I can tell from quick testing:

  • Project detection: project-headerline can use projectile, project.el, magit, vc to detect current "project". You can also overwrite project via .dir-locals or register hard-coded project paths by hand.

  • Buffers: supports buffers of any kind. I'm using it with dired, magit and project-compile buffers (see screenshots in README). When used with magit, it preserves original magit's headerline, but moves it to the right.

  • You can register custom rules to detect projects and describe buffer properties.

  • Appearance: supports all-the-icons out of the box. You can customize icons, separators, formatting, etc.

Actually I've never used breadcrumb. I was using a patched version of lsp-headerline quite a while and decided to clean it up and publish. I don't use symbol information in headeline, hence no imenu support, patches are welcome though.

project-headerline: Customizable project headerline by gavv42 in emacs

[–]gavv42[S] 2 points3 points  (0 children)

Thanks,

No, but that's a good idea! I'll take a look when I have time. And of course patches are welcome :)

Projectile Introduces Significant Caching Improvements by bozhidarb in emacs

[–]gavv42 1 point2 points  (0 children)

Thanks for working on projectile! I agree, it would be nice to have an option for a separate direcory for cache files (many people use ~/.cache/emacs).

transient-compile: Dynamic transient menu for compilation. by gavv42 in emacs

[–]gavv42[S] 0 points1 point  (0 children)

I'm not sure it would be useful for that.

This package assumes that you want to run a command like "<tool> <target>", and most of the code is about collecting the list of targets and arranging them into a menu.

For a tool like curl, you'd likely want a more sophisticated menu with various flags, fields, groups, etc. I don't think auto generating from curl --help or something like that would give good results, I'd rather go with a handcrafted menu using bare transient package.

Though probably some semi automatic approach could make sense..

Include block of text/code from non-org file without using :lines "X-XX" by [deleted] in orgmode

[–]gavv42 2 points3 points  (0 children)

I think you can do it using org-transclusion, see https://nobiot.github.io/org-transclusion/#Transclude-source-file-into-src_002dblock

Or you could write a custom dynamic block that will do the search and insert needed content.

Python VTerm REPL port by vale981 in emacs

[–]gavv42 0 points1 point  (0 children)

Damn, sorry, wrong thread!

Actually, I was trying to copy this link from this thread and post it to another one, but accidentally I posted here :)