I kind of want to go back in time and make it so that the original yes always printed the first letter of the name it was called by. That way you could symlink any name you like to it and it would do the right thing. Called as no it would print ns, etc. The optional parameter would still be there for longer strings or alternate uses.
The reason time travel would be needed is that there’s bound to be, or have been, someone who has done something weird regarding symlinking yes that relies on it always printing y when it has no parameter, and the name trick would be a breaking change.
I’m going to assume you’re not kidding, in which case, no, I mean the first letter of the command name it was called by.
There are already commands that do this. For example, on my machine, ex is the head of a symlink chain that leads to the vim text editor’s executable and if I run ex, vim will know that it was started with the name ex and will start in ex mode. ex was an editor that worked in a different way but was vim’s ancestor, so backwards compatibility is built right in for those strange people who love ex, (or have some kind of automation reliance on it being present).
Usually, the main command has a command line option that achieves the same effect as the special name. Here, vim -e is the less clever way to start vim in ex mode.
For yes, symlinking the name no to it and then calling that should arguably cause it to print n repeatedly, but it doesn’t, for historical reasons, hence my suggestion to go back in time and make it act differently.
(None of this touches on the fact that the GNU philosophy wants nothing to do with clever tricks like this. They prefer to compile separate executables for each and every use case. For example, most Linuxes have dir and vdir as variants of the ls command. Their functionality could have been implemented through this symlink trick, but instead there are three near-identical executables taking up space instead.)
forced consent
$ no bash: no: command not found $ yes y y y y y ...$ yes n n n n n n n ...I kind of want to go back in time and make it so that the original
yesalways printed the first letter of the name it was called by. That way you could symlink any name you like to it and it would do the right thing. Called asnoit would printns, etc. The optional parameter would still be there for longer strings or alternate uses.The reason time travel would be needed is that there’s bound to be, or have been, someone who has done something weird regarding symlinking
yesthat relies on it always printingywhen it has no parameter, and the name trick would be a breaking change.you mean like
yes "$(whoami | cut -c1)"?I’m going to assume you’re not kidding, in which case, no, I mean the first letter of the command name it was called by.
There are already commands that do this. For example, on my machine,
exis the head of a symlink chain that leads to thevimtext editor’s executable and if I runex,vimwill know that it was started with the nameexand will start inexmode.exwas an editor that worked in a different way but wasvim’s ancestor, so backwards compatibility is built right in for those strange people who loveex, (or have some kind of automation reliance on it being present).Usually, the main command has a command line option that achieves the same effect as the special name. Here,
vim -eis the less clever way to startviminexmode.For
yes, symlinking the namenoto it and then calling that should arguably cause it to printnrepeatedly, but it doesn’t, for historical reasons, hence my suggestion to go back in time and make it act differently.(None of this touches on the fact that the GNU philosophy wants nothing to do with clever tricks like this. They prefer to compile separate executables for each and every use case. For example, most Linuxes have
dirandvdiras variants of thelscommand. Their functionality could have been implemented through this symlink trick, but instead there are three near-identical executables taking up space instead.)Or make your own package? call it
affirm(more wholesome), write it in Rust (of course), and take onyes.yesn’t