Suggestion: non-hidden config files for TC

[samedirection]

Posted in bugs, since I suggest that it is one.

In some future version, could the TC config files in /opt be changed to visible (non-dot) files?  Perhaps put into a sensible directory like /opt/tcconfig or /usr/local/etc/tc?  I realize this is a small change which affects many places in the core and some extensions as well, but (1) it tripped me up the first time I went looking for .filetool.lst and friends.  I can't be the only one this has happened to.  (2) it's uncommon (maybe even unknown) in Linux to have system wide config files hidden as dot-files.  If you forget exactly where they are and you just go hunting with cd and ls, you won't find them, unless you know that they're hidden.

I know the current names have a historical basis (since their predecessors were once located in the home directory, way back in the B.T.C era), but perhaps, if you agree to the change, it could at least be slated for some future migration (to 2.3 or 3.0).  Thanks.

[alu]

sorry if i misunderstand your request, but i don't feel it as a big problem since these kind of files don't seem to be system wide config files. f.ex.: i consider filetool.lst as a file to stock personal preferencies which don't affect the system deeply; same for bootlocal.sh and s.f.; i confess that i am using mc, so dot directories are not hidden and i can handel them like usual directories

[samedirection]

Sure.  There will be others that don't see the problem.  It's not broken from a *system* point of view.  It's just a change I think worth making for the sake of users.  /opt/.filetool.lst is both a personal configuration file and a system configuration file.  Any system wide configuration files (in /etc, for example) only persist if you put them in .filetool.lst.  Likewise any firmware, extra keyboards, cron settings, updatedb database, etc.  But it's not these files' function that makes me raise the request, it's their location.  Outside of $HOME, files of any sort just aren't hidden on a Linux system.  The only real function of dot files (historically) is not to clutter up your home directory.  Everyplace else on the system, you WANT to see them. 

[mikshaw]

When I first saw the dotfiles in /opt back in B.T.C. (giggle), I thought it was a little odd, too.  I never thought of it as a bug or anything that needed changing, though...just a little odd.

Then again, like alu I also use mc and "hidden" files are never hidden. To me the dot is just a visual clue that a given file is a configuration file.  I never liked the concept of hiding files.  It's just an added complication when you have to manually toggle hidden files in order to read or edit them, especially if the file dialog doesn't have a one-step toggle *cough*fltk*cough*.  Even in Windows one of the first things I would do was make sure all files and filename extensions were visible.

[roberts]

Hidden files are not just for keeping a directory tidy.

IMHO they afford some protection against accidental deletion.

Most of the files in question are directly related to a successfull backup. Achieving such is of course paramount, thus the reason behind my madness to 'protect' them.

BTC, approximately 6 years ago, they were not hidden and the effects were lost data due to backup failure. It is interesting that 6 years later this request surfaces.

The only file that is not in such catagory is .backgrounds, since I am working in this area, I will accomodate this request to change it to backgrounds.

Note also that I provide in the Tools section of them menu, easy access to add filenames to .filetool.lst and .xfiletool.lst as well as other guis to access the others. There should be little reason to directly edit them and certainly no reason to delete them.

[samedirection]

There should be little reason to directly edit them and certainly no reason to delete them.

Well, no one wants to delete them! And with respect to the GUIs, you're of course speaking of the full TinyCore.  If you don't pull in the X environment (e.g. on microcore alone ), you have to edit the files directly.  And anyway, even in TC, I much prefer to see what's happening under the hood whenever posible, so I've never used the .filetool.lst GUI.

Anyway, like I said.  I know not everyone will see this as something that should be changed, or that it's worth the effort if even if it 'should.'  I'm content with things the way they are.  I just raised the issue because I saw advice like, "be sure and add file xxx to your filetool.lst"  and went through the obvious places looking for it with 'cd' and 'ls', and was baffled.  Only later I realized that this was because I've never seen Linux configuration files hidden outside $HOME.  Thanks for considering this request.  Over and out.

[roberts]

"be sure and add file xxx to your filetool.lst"  and went through the obvious places looking for it with 'cd' and 'ls', and was baffled.

It is well documented in Core Concepts Backup/Restore section:

Code: [Select]

After setting up your new system, you will want to save your settings. There is a file called /opt/.filetool.lst. It is a simple text file of files and directories listed one per line using a full path that the user wants to save/restore. Use any of the GUI tools provided on the Tools menu or any editors available via extensions or vi to change/update (e.g., select Beaver, then open /opt/.filetool.lst).