On Donnerstag, 27. August 2020 16:44:52 CEST Al Viro wrote: > > No matter which delimiter you'd choose, something will break. It is just > > about how much will it break und how likely it'll be in practice, not if. > ... which means NAK. We don't break userland without very good reasons and > support for anyone's pet feature is not one of those. It's as simple as > that. > > > If you are concerned about not breaking anything: keep forks disabled. > > s/disabled/out of tree/ > > One general note: the arguments along the lines of "don't enable that, > then" are either ignorant or actively dishonest; it really doesn't work > that way, as we'd learnt quite a few times by now. There's no such > thing as "optional feature" - *any* feature, no matter how useless, > might end up a dependency (no matter how needless) of something that > would force distros to enable it. We'd been down that road too many > times to keep pretending that it doesn't happen. Well, it could be an option per mounted fs, but I know -> NAK. On Donnerstag, 27. August 2020 18:29:35 CEST Dr. David Alan Gilbert wrote: > * Al Viro (viro@xxxxxxxxxxxxxxxxxx) wrote: > > On Thu, Aug 27, 2020 at 04:23:24PM +0200, Christian Schoenebeck wrote: > > > Be invited for making better suggestions. But one thing please: don't > > > start > > > getting offending. > > > > > > No matter which delimiter you'd choose, something will break. It is just > > > about how much will it break und how likely it'll be in practice, not > > > if.> > > ... which means NAK. We don't break userland without very good reasons > > and > > support for anyone's pet feature is not one of those. It's as simple as > > that. > > I'm curious how much people expect to use these forks from existing > programs - do people expect to be able to do something and edit a fork > using their favorite editor or cat/grep/etc them? Built-in path resolution would be nice, but it won't be a show stopper for such common utils if not. For instance on Solaris there is: runat <filename> <cmd> ... which works something like fchdir(); execv(); you loose some flexibility, but in practice still OK. > I say that because if they do, then having a special syscall to open > the fork wont fly; and while I agree that any form of suffix is a lost > cause, I wonder what else is possible (although if it wasn't for the > internal difficulties, I do have a soft spot for things that look like > both files and directories showing the forks; but I realise I'm weird > there). It seems to be both a file & dir feature on all systems that have that concept. So people would expect it for dirs on Linux as well. Best regards, Christian Schoenebeck
