151–160 of 204 posts
Earlier quoted context omitted.
I see now. The parenthesis don't feel like a convenient syntax.
Scheme could be a good language (for fans?) if it is not used interactively.
My number-one wish for a NGS: Undo! Take, for example, rm. The hoops we have to jump through when accidentally rm'ing a file are ridiculous [1]. But in most cases (smallish, non-secret files), rm should be trivially undoable. Windows gets this right: By default, files are not deleted, but moved to trash. If there is not enough space in trash, Windows warns you. Or, if you really want to delete a file instead of movin…
> map `rm -rf ` (grep "*.tex" (ls))
[0]: I haven't had much experience with FOOP, however.
Earlier quoted context omitted.
ls | grep 'cheese\|fish' | head -n 5 | while read -r i …
With Zsh: > touch {dark\ red,green,light\ blue}{cheese,fish\ fingers,fruit} > ls -1 *(cheese|fish)*([1,5]) dark redcheese dark redfish fingers greencheese greenfish fingers light bluecheese > for i in *(cheese|fish)*([1,5]) ... Since that's shell globbing, it can cope with any spaces, newlines etc.
My number-one wish for a NGS: Undo! Take, for example, rm. The hoops we have to jump through when accidentally rm'ing a file are ridiculous [1]. But in most cases (smallish, non-secret files), rm should be trivially undoable. Windows gets this right: By default, files are not deleted, but moved to trash. If there is not enough space in trash, Windows warns you. Or, if you really want to delete a file instead of movin…
Although I kind of agree with you, I'll play the devil's-advocate: If you actually care about the file, it should have a backup that you can restore from anyway. And, depending on the file, that backup should be source-control.
I have btrfs snapshots run on the fileservers at 10 minute intervals. Which, of course, captures the entire filesystem state, not just files that you have deleted by accident.
I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the fish shell, but in the real world, it never seems to be installed across the farm, and convincing the older SysAdmins to install it is more trouble than it's worth. We should be focusing on saner bash defaults, since it's the most common shell in use. We should…
If it's hard to try to convince them about fish... try to convince them to enter commands in a browser over a web stack, as a "shell". If they are conscious about the parts involved and the security repercussion, maybe they will say the same: "no". On the other side, technology is not advanced only by older SysAdmins, and it's nice to see new projects, experiments and developments.
What? I had never heard of fish before and this is making me nop out pretty quickly.
Earlier quoted context omitted.
Those can all be seen as tweaks to existing shells. With regards to... "* Have some simple, easy to follow rules which let me work on files that have spaces in their names, without having to remember the various commands with various special cases (like -print0)." I'm not sure I understand what's hard about files with spaces in their names. I'd say it's easy enough to work with such filepaths by using tab autocomplet…
When you pipe the output of one command into another, e.g 'ls | wc' (obviously a dumb example), the second command will split the filenames on spaces and so will not run properly. The workarounds for this all involve nasty extra parameters for different commands (e.g. the -print0 example)
It also has nothing to do with the shell, nor does the general case of pipes you present below. Your shell redirects the output from ls to the input of wc. If you don't like the simple approach that tools consume and produce arbitrary text in a manner it sees fit for its purpose,, maybe it's your operating system that you have a beef with.
I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the fish shell, but in the real world, it never seems to be installed across the farm, and convincing the older SysAdmins to install it is more trouble than it's worth. We should be focusing on saner bash defaults, since it's the most common shell in use. We should…
Disagree. A shell is a domain-specific programming language, and all the existing such languages are terrible. We'd be better off with a properly designed language, like a shell language based on OCaml: Caml-shcaml [1].
[1] http://users.eecs.northwestern.edu/~jesse/pubs/caml-shcaml/
[WARNING, RANTY] This is a blue-sky project. Completely new, with no legacy dependencies. AND YET THE DEVELOPER CHOSE TO WRITE IT IN C. WHY FOR THE LOVE OF GOD, WHY? Could someone explain this to me? Is it developer hubris, believing in one's own infallibility that a single exploitable stack frame or buffer overflow couldn't possibly happen "on my watch"? If you need a native binary, your options are endless. Rust, G…
Do you think it's a bad idea that git and the Linux kernel are written in C? Is the possibility of a buffer overflow important in a program that's not processing input from random people on the internet?
Earlier quoted context omitted.
This to me makes too many assumptions. I'm sorry but experience doesn't mean wise. And in many cases experience can mean complacent or scared of change.
Neither experience not wise was used. Older was used. You are comparing two possible substitutions with each other, not the original term. There's not much point to that.