ashrc aliases

[hiro]

In my view prompting for overwrites is generally OK in order to create less frustration for new users, but if you rely on this and switch back to some debian you may lose all your files

Scripts may also rely on standard cp behaviour and you can see that even in tc base we have to hack around this problem by running the yes command every single time we use cp.

tldr: sh aliases are annoying and should only be set by the user itself.

[maro]

Whilst I agree that it can be quite annoying to be treated like a newbie (with having to answer with YES) there are (at least) two ways to overcome this "nuisance" (without changing '~/.ashrc'):

• either use the '-f' option to force an overwrite (e.g. cp -f new old), or
• avoid the alias by spelling out exactly which 'cp' command is to be used (e.g. via /bin/cp new old).

[roberts]

Anyone capable of using a backup would edit to suit.
No need to accept defaults unless you boot from CD and/or choose not to use a backup.

[hiro]

With my objections in mind do you really think this is a sane default?

[cosmin_ap]

Btw, what about moving bash aliases from /usr/local/etc/bashrc to /etc/skel/.bashrc? It would be consistent with the way ash is configured (not sure how bad would that affect existing users though).

Another suggestion (I remember seeing this already but can't find the link right now) would be to have one ~/.aliases for both ash and bash, and then an user would just empty that file from its home dir and be done with it if it doesn't like aliases

[tinypoodle]

Btw, what about moving bash aliases from /usr/local/etc/bashrc to /etc/skel/.bashrc? It would be consistent with the way ash is configured (not sure how bad would that affect existing users though).

Another suggestion (I remember seeing this already but can't find the link right now) would be to have one ~/.aliases for both ash and bash, and then an user would just empty that file from its home dir and be done with it if it doesn't like aliases
 

Sounds like a bad idea to me mess with the clear current distinguishing between base and optional extensions, that is one of the aspects of TC I have come to appreciate.

Particularly starting to place a file of an extension into /etc/skel might be setting a doubtable precedence.

[cosmin_ap]

the question it boils down to is this: is it a goal of tinycore to have extensions that work out of the box? if yes, then they need to have a way to integrate with the shared aspects of the system at the time of install and /etc/skel and ~/.aliases are shared resources.

if I install extension X which needs a default config file in each users' home directory to run, then that extension needs to write in /etc/skel (or in /usr/local/etc/skel and make adduser a wrapper that uses that directory), and even write to existing homes at the time of install (I see how that could be considered too intrusive though, especially when /home is persistent but you want to try out some extensions which don't have a way to ask you to cleanup up after themselves).

now ~/.aliases is definitely a user thing and not a distro thing (think of a portable home directory), while /etc/aliases is the distro thing, and /usr/local/etc/bash/aliases is the extension thing -- as long as there's a separation between the three and extension people know about it, i see no problems. what do you think?

[hiro]

Before this I didn't even know what skel is...