On Fri, Sep 05, 2003 at 01:10:34PM +1200, Volker Kuhlmann wrote: > I am not interested in having dumb shell arguments.
i am not going to start one, i just want to satisfy my curiosity. > The by far most annoying I can remember is that esc-bs only erases to > the previous period, so keeping a finger on bs is actually faster. I > want it to erase to the previous /, just like tcsh does it. i second being annoyed at not being able to erase to the previous / however, i didn't know about esc-bs, and after trying it i found that it DOES erase to the /. debian woody, bash version 2.05a-11, default config. > I never said bash is bad, just that making it work the way I > need it takes more time than I have. which falls exactly in line with my argument about not wanting to configure things. > > i find it terribly annoying that filename completion uses <ctrl>-d in tcsh > This is obviously wrong. it may be wrong, but not abviously so. i am not saying that tcsh is bad, but making it work the way i need it would take more time than i have. > > in bash i can hit <tab> anywhere, and filename completion is done at > > that point. > And you didn't bother trying this in tcsh? i DID try it. it does not work on my setup, just like esc-bs seems to work differently on your bash compared to mine. > If you're talking about command completion, correct - good thing too, > completing for commands at the place where a command expects filenames > would be daft indeed. no, i don't mean that, of course command completion does and should only work on the first word, the rest is filename completion sorry for the confusion. > Thanks to CF for the tip about esc-d (to force > command completion in the middle of a filename). that would force filename completion there. > > i don't reconfigure programs if i can avoid it, because i'd have to do > > it all over again if i get a new account somewhere. > True, but not really a good argument. it is exactly the argument you made above. > For the same reason you never > configure your Linux box after installation, because next time you > install, you'd have to do it again? i said "if i can avoid it", and i meant configuration that is not unique to a machine. abviously settings that need to differ from one machine to the next (like networking) must be configured, but for the rest i expect usable defaults. > Besides, the default > configurations for interactive shells are not the same on all Linux > distros anyway, therefore a personal setup job is required. you accept this as reality, i reject this because it is a big problem. a personal setup job should NOT be required. this is what makes linux so complicated, people keep asking if it matters which distro they take. it should NOT matter for the end user. on suse i discovered that less is set up to wrap lines. it didn't even occur to me that someone could get the idea to even have such a feature in less, so i had no clue that i was missing something, and could have reconfigured it. ie: i didn't even know that there was something to configure. this goes for all software. the options are way to complex to allow any one person to know them all, or study them all, just to configure the machine to your tastes. such a task takes years. but people expect to be productive USING the machine from the first day, and not waste time learning all the configure options until it works. distributions should stick with the defaults a program provides. this also helps with documentation, because you only have to write one set of docs that works on ALL distros out there. i don't start configuring things after i have used a program for some time, by then i will have come to like enough features and found things i want to change that it warants spending some time to make it even more usable. but if i start a program and it presents itself as unusable in the beginning, i'll just turn it off right there, and look for one that is usable. the one with the most usable defaults wins, and i'll take it from there. greetings, martin. -- Pike Conference 2003 - Sep 25-27 - http://pike.ida.liu.se/conferences/2003/ -- interested in doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer working in europe open-steam.org unix system- bahai.or.at iaeste.(tuwien.ac|or).at administrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin B�hr http://www.iaeste.or.at/~mbaehr/
