Lsd: The next gen ls command

you have it already: https://hyper.is/

Add an out of band channel to ssh and your favorite ssh client/terminal emulator. Teach it that information in the out of band channel is used to render html, jupyter notebooks, or whatever. On the remote side, have your sshd set an environment variable that lets apps know the side channel is available, and then df can produce cute little pie charts or historic usage graphs. Ls can produce thumbnails if run in a directory with that kind of media and the appropriate args are used.

Honestly, it's likely that nothing special is needed on the ssh part of things as simple port forwarding and environment variables would do the trick.

No. Specifically, if the user issues the command line "cd ./foo; bar" a bash process is created that arranges for the wd to be ./foo during the execution of bar, but that cd command will have no effect on any subsequent command line (which will be evaluated by a different bash process).

If the target audience for this code were users other than just me, then it might not pay to arrange things that way, but all the motivation I personally needed to remember to treat the cd command differently while using the code I wrote was the very pleasant thought that my giving up on maintaining normal behavior of the cd command means that for my usage patterns, which again do not including using the code I wrote to interact with REPLs[1], no state need be maintained by any code whatsoever outside of the Emacs process except for the usual, expected state of the file system and any state internal to any bash processes and any of their child processes that are currently executing a command line.

Standard Gnu Emacs contains a M-x cd command, and that does modify the wd in a way that persists through the issuance of multiple command lines. (Again, I arranged for Emacs alone to keep track of the wd.)

[1]Standard Gnu Emacs contains the command M-x run-scheme, M-x run-python, etc, for interacting with a Scheme REPL, a Python REPL, etc. I do not happen to use any of them, but if I did start to use one of them, I probably would not feel tempted to re-write it the way I re-wrote shell mode (a.k.a. M-x shell) because I can think of no easy way to arrange things so that no state persists inside the REPL between command lines. What is special about interactive shells is that there is this single dinky piece of state, the wd, that if treated differently, makes the interface between the terminal or terminal-like thing and the shell process "connectionless" in the way that HTTP is connectionless: namely, after a command line finishes, the shell process and the terminal-like thing can just forget about each other.

I would imagine that this arrangement would be even more worthwhile for running shell command lines on lots of remote machines, but haven't written any code to effect it because I personally don't do that often.

ADDED. If I found myself writing "VAR=3 foo command" more than twice I would probably arrange for "VAR=3" to be permanently added the appropriate emacs variable (namely, process-environment IIRC). Basically, in my life the only environment variables that matter can be set once in a config file somewhere and forgotten.

Thank you for your answer.

What I mean, it doesn't seem to be possible to make it forget about .gitignore files completely. For me, it doesn't make any sense for my grep tool to pay any attention to .gitignore files (let alone info/exclude and such), these are 2 completely separate tools. I might occasionally want for some project to put into .rgignore the same line as I put in .gitignore, but that's an explicit choice. Actually, most of the time I have a few global ignores (which is possible to do with ripgrep) and an occasional .agignore file, while pretty much every git directory has .gitignore of some sorts. This is not something I can get around with, since while .agignore (.rgignore) is totally personal, .gitignore affects everyone who works on the project and serves explicitly to indicate that you ought not commit these files.

If I put "--no-ignore" in my .ripgreprc, it skips both .gitignore and .rgignore files, which isn't obviously what I'm trying to achieve.

One more thing (even thought it it possible to get around it by writing my own bash function that would invoke rg) is that unlike the ag, rg doesn't seem have "--pager" option, which I always use heavily, by setting half a dozen of parameters for `less` when grepping.

So these are what I consider a deal breakers and reasons why I didn't switch to rg: while it's true that in some cases I would appreciate a better performance, it's extremely rare that I grep something over a 9.5GB file. And conveniently search for a substring in a project is something that I'm in need multiple times a day.

BTW, noticed one more minor quirk right now: export RIPGREP_CONFIG_PATH="~/.ripgreprc" doesn't work (but RIPGREP_CONFIG_PATH="/home/$USER/.ripgreprc" does, so it's probably almost never an issue).

Thanks, this works, I didn't see that option. --no-heading is also useful. (other comment)

that's it, thank you!

Go to your dircolors file in /etc/dircolors, if it’s not there create it first with the dircolors command. Make sure your terminal is using a nerdfont patched font. Set colors in dircolors for various file types to whatever you want and append or prefix whatever icons you want to use. Done. Define granular rules for other extensions if you wish.

Regarding segfaults, when I was interviewing devs for C++ roles, I'd ask questions about a simple function like this:

  std::string foo(bool flag)
  {
    if (flag)
      return "true";
  }

Questions I'd ask: * Is the function well formed (Yes - functions need not return a value on all paths due to C ancestory, even if the return type has a non trivial actor - not sure if this is still considered well formed, but I think it was as least to C++11) * what happens if 'foo' is called with true? (Returns "true" as one would expect) * what happens if 'foo' is called with false? (Undefined or implementation defined behavior, but generally nothing nice - segfault, acces violation, etc)

* if it crashes, where, when and why does it crash? (Technically since its undefined, nearly any answer here suffices, if it can be backed up. Since practically, most optimizing compilers assume UB can never happen, when you return nothing from a non-void function, the compiler will attempt to invoke the destructor of a non existent object instance (assuming non POD) and boom.)

I asked this because it was a distilled example of a real world rare crash that was extremely difficult bug to track down because the crash location is often know where near the offending function.

I remember getting into a heated argument with a coworker when I claimed it should have been a compilation error. IIRC, he claimed it to be a halting problem and that the compiler couldn't determine that all paths didnt return a value. I called BS, citing at the time (circa 2004) that the new compiler on the block for C# could reliably emit errors when not all return paths returned a value.

I also like it that in C++, it's a very rare example of a very terse example dealing with a number of topics such as undefined/implementation defined behavior, debugging, compilation settings (warning levels, etc) all in a mere 4 lines of codes. With 4 LOC, which is straight forward and simple for the candidate to mentally parse, I can gleam a lot about their understanding of the language (and it's potential pitfalls).

Sorry if this got a little long winded and ranting.

Very importantly, Rust's safety guarantees help with "fearless concurrency", and better multithreading accounts for most of the performance gain we see in these new tools.