3 ms·

> I'd even appreciate a "trash mode" for rm as default. Then you do something like "rm purge" and only then it actually kills everything put in between calls. T

> I'd even appreciate a "trash mode" for rm as default. Then you do something like "rm purge" and only then it actually kills everything put in between calls. Tons of user documents would have saved that way, instead of "just be careful because that's how we always did things". And of course some --doitnow flag could just delete stuff immediately. That will break a large chunk of scripts that use rm. Say someone with sufficient clout implemented this, dumped the information into some release notes, even made it widely known via various internet forums. Inevitably, what will happen is that we get a split: some who do not want to use the "improved" tool as they have other more pressing concerns, and others who view it as progress. If anything, there is already a ton of fragmentation even in such basic utilities found in coreutils (BSD vs GNU differences, not immediately available on Windows, etc). And the funny thing is that even if unity is practically achieved for some time, someone will want to scratch a new itch, repeating the cycle.

coldtea 10y ago
>That will break a large chunk of scripts that use rm. Say someone with sufficient clout implemented this, dumped the information into some release notes, even made it widely known via various internet forums. Sure, that's why I talk about compatibility etc lower. As I wrote, the best way imho would be to create new versions of the old utils, with changed prefixes/names, and have people slowly migrate to them. It's not impossible, people can and do adopt new cli utils. The old ones could still be there for the compability layer (for old scripts etc), but new stuff could be written in the new ones. And while we're at it, a new shell too. Even zsh is 1990's technology for 1990's needs. >And the funny thing is that even if unity is practically achieved for some time, someone will want to scratch a new itch, repeating the cycle. That's how you get better stuff though, with cycles. Not with religious adherence to backwards combatibility. The problem is most of those cli userland tools only had one major cycle, when the old UNIX/BSD userland got remade as GNU, and added new switches, options etc. Contrast with how better OS X is compared to Mac OS circa 1988 or Windows 10 compared to Windows 3.1.
- gajjanag 10y ago
  > That's how you get better stuff though, with cycles. This is an assumption that is not necessarily true. In the short term, there are plenty of examples of places where it is not true. As for this being true "asymptotically", that is a hard to verify assumption. What is true is that cycles result in something new. New does not necessarily mean better. The examples you give below are examples where the cycles have worked; there are examples where it has not.
  - coldtea 10y ago
    >This is an assumption that is not necessarily true. In the short term, there are plenty of examples of places where it is not true. Any example? Because cycles (and I could have said "iteration") is what got us from bone tools to spaceships... >The examples you give below are examples where the cycles have worked; there are examples where it has not. That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results. E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them.
    - gajjanag 10y ago
      > Any example? Really depends on what means by better and what one values. Still, here are some relatively unambiguous ones: global warming/climate change, the fragile nature of the current equilibrium wrt nuclear weapons. Maybe long term we will solve them, but in the short term we are worse off. > That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results. > E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them. There are costs associated with each iteration, and in the context of dating, there is a threshold to the number of rejections. Obviously, at some level any work is an iteration on the existing body of work, in which case your point also does not mean much. My point is that in certain cases it can be best to leave things as they are. "Fixing" rm is one such thing for me: there are trivial workarounds via aliases (can be shipped by a distribution) for those who really care. I am sure your thoughts are not unique on this: people must have tried "fixing" rm in the past, and judged it not worth it. One is completely free to work on "improving" something. However, there should be no expectations that others find it an improvement.

coldtea 10y ago

>That will break a large chunk of scripts that use rm. Say someone with sufficient clout implemented this, dumped the information into some release notes, even made it widely known via various internet forums. Sure, that's why I talk about compatibility etc lower. As I wrote, the best way imho would be to create new versions of the old utils, with changed prefixes/names, and have people slowly migrate to them. It's not impossible, people can and do adopt new cli utils. The old ones could still be there for the compability layer (for old scripts etc), but new stuff could be written in the new ones. And while we're at it, a new shell too. Even zsh is 1990's technology for 1990's needs. >And the funny thing is that even if unity is practically achieved for some time, someone will want to scratch a new itch, repeating the cycle. That's how you get better stuff though, with cycles. Not with religious adherence to backwards combatibility. The problem is most of those cli userland tools only had one major cycle, when the old UNIX/BSD userland got remade as GNU, and added new switches, options etc. Contrast with how better OS X is compared to Mac OS circa 1988 or Windows 10 compared to Windows 3.1.

gajjanag 10y ago
> That's how you get better stuff though, with cycles. This is an assumption that is not necessarily true. In the short term, there are plenty of examples of places where it is not true. As for this being true "asymptotically", that is a hard to verify assumption. What is true is that cycles result in something new. New does not necessarily mean better. The examples you give below are examples where the cycles have worked; there are examples where it has not.
- coldtea 10y ago
  >This is an assumption that is not necessarily true. In the short term, there are plenty of examples of places where it is not true. Any example? Because cycles (and I could have said "iteration") is what got us from bone tools to spaceships... >The examples you give below are examples where the cycles have worked; there are examples where it has not. That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results. E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them.
  - gajjanag 10y ago
    > Any example? Really depends on what means by better and what one values. Still, here are some relatively unambiguous ones: global warming/climate change, the fragile nature of the current equilibrium wrt nuclear weapons. Maybe long term we will solve them, but in the short term we are worse off. > That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results. > E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them. There are costs associated with each iteration, and in the context of dating, there is a threshold to the number of rejections. Obviously, at some level any work is an iteration on the existing body of work, in which case your point also does not mean much. My point is that in certain cases it can be best to leave things as they are. "Fixing" rm is one such thing for me: there are trivial workarounds via aliases (can be shipped by a distribution) for those who really care. I am sure your thoughts are not unique on this: people must have tried "fixing" rm in the past, and judged it not worth it. One is completely free to work on "improving" something. However, there should be no expectations that others find it an improvement.