![]() ![]() :) As a class, we have been conditioned not to expect or demand too much from command-line utilities from the Unix family tree. I'm a Windows user, so I consider myself lucky that it works at all. Without all these cool things, we would just sit there and cry over our uselessness.Įd: I read below that ls does that in interactive mode only, maybe it’s not that bad then. The workaround is to run it with a cli option – a very thing that unetbootin was created for to skip. There is also an eternal “FAT” label issue in unetbootin app, which resurrects every time Apple changes its fdisk output format (in every release, as it seems). I can guess the reason – ifconfig was bad and ip is good. Now it’s called ‘ip a’, and there is no ifconfig. I remember how recently I wanted to check network interfaces on some machine and commanded ‘ifconfig’. Good software doesn’t point fingers at you, it just works. Modern culture may not appreciate that little ‘compat’ thing, but it is essential if you want something to continue to work and not just stop and wait for someone’s educated guesses. You’re a sophisticated script after all, not one of these who require a human with a debugger. If you’re a script that has to run on various versions, then maybe it’s time fix yourself and use find. If you’re a script, it breaks you in half. ”The old behavior was the bad one the new behavior is good” The way it handles filenames with ASCII apostrophes/single quotes works particularly well (wraps the filename in double quotes instead of single quotes) and makes it very easy to copy and paste filenames to and from the terminal.īest of all, this change only applies when standard output is a TTY device so this does not break any shell scripts (even though parsing `ls` is a bad idea in any case) and is still compliant with the POSIX specification which states that “If the output is to a terminal, the format is implementation-defined”. Now the filename listings are much more readable and it takes less cognitive effort to take it all in. ![]() ![]() Before this change, I had to use the `-1` option to ensure that each filename was listed on a line by itself. With this change it’s much easier to see where one filename ends and the other begins. I deal with a lot of filenames with spaces and think this change is a great improvement for listing such files. I really don’t understand the hate for this change. It's something we already do but it's precise like JSON.) I think it's more generally useful in a lot of places. (If anyone is interested in QSN, please contact me. So it's basically like what ls and stat do, but it's more precise. The QSN encoder does UTF-8 decoding with a specific error recovery mechanism. (JSON can't express arbitrary byte strings.) It adapts Rust's string literal syntax to express arbitrary byte strings precisely and losslessly. I just changed Oil to use a well-defined format I called QSN (quoted string notation): For example you can touch "x$ANSI_TERMINAL_CODES" and if you do "bash x?" or "python x?", then your terminal will change color because of the escape codes printed back to the terminal. Most command line tools are not aware of stuff like this. (it looks like it's outputting a valid shell string, except with extra quotes) However GNU stat (which I think is also in coreutils) does something similar, but weirdly messed up: It shows the invalid byte and then keeps decoding with error recovery: Here is an invalid utf-8 byte and then a valid utf-8 sequenceĪnd here 'ls' does better than other tools that display filenames. ![]() Actually I recently found that coreutils and ls behave fairly well with funny filenames: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |