Quote:

Well I think - we will some time have a full blown ixemul/gnu/unix environment, because it will be needed by some badly ported apps. Why not keep these utilities in gnu/bin if it is in the path and still you can ping from shell by just typing ping, not sys:gnu/bin/ping?

Technically they are alien to AROSDOS, and should be separated...

aros has strayed a little from the amiga way, i pretty much agree!

except for 3, anything commonly executed in CLI (shell) should be in C: (i think)

Hello,

Aros really needs directory structure cleanup and some GOOD decission on file placement. Simple and obvious directory structure was one of the things I loved in AmigaOS.

I am just in the middle of moving around files from WMVAros distribution so it gets more logical (I am really anal retentive), also thinking about better placement for some system files - nothing really radical - just small changes to make it more simple and elegant.

I realise that decission about file placement should not be one crazy man's ideas - it should be agreed by all people to be "amiga-style", simple, elegant, logical and practical. So to start, here I give you my RFC...

What currently works for me:

1) remove of sys:rexxc - it is a bit pointless to have separate directory in system root with only 2 files, don't you think so? If there's any reason for it - tell me. I really have no idea, why rexxc executables were separated, so for now on I keep them in C:

2) more about C: - notice, that there are files that are run only once, and there's really no way user will ever want to run them by hand - i mean: conclip, decoration, iprefs, rexxmast and other, which I will describe later. For now I store them in a subdirectory in C, this subdirectory is not in path (as user will not need these commands)

3) I created new directory - named GNU in SYS: This directory contains all non-amigados specific commands (mainly gnu) with unix directory structure. So all commands that do not use readargs are placed in my SYS:GNU/bin (which is added to path). I really feel that executables that use gnu or unix style commands should be separated, together with their crap. Note that amitcp commands such as ping and so on reside there.

4) System, tools, utilities, extras are really smallest problem. What gets where depends on one's liking, although I think at least some files should have standard places. What I have is:

System: (the logic behind is that these are like "Administrator tools", nod user tools)
Images
Themes
Wanderer
About
FixFonts
Format
FTManager, ttemanage (as fountain was here, if I remember correctly - do we really need both?)
HDToolbox
InstallAROS
Installer

Tools: (the logic: commodities + programs used to open various documments)
Commodities
More
Multiview
Editor

5) I don't really find the "package" system in ENV:sys/packages appealing, but I understand this is some agreed standard in AROS, so what I did is to rewrite all .../s/package-startup scripts to have relative, not absolute paths. What's the use for package system if you have to change paths in several files, when you move application directories?

6) and finally the change that may cause most "huh?!"s and "what?!"s: services. As mentioned in 2) there are files which are run only once and which user should not be able to run. Currently we have many "run >NIL: <NIL: something" together with messy assigns and paths in startup-sequence or user-startup. What I did was:

- create s:inittab (sorry for crappy name) that starts "service scripts". The contents:

execute services:conclip.service start
execute services:rexmast.service start
execute services:iprefs.service start
execute sercices:decoration.service start
execute services:arostcp.service start
execute services:dhcp.service start
execute services:yafs.service

and so on.

services: which is S:services contains all scripts responsible for starting and stopping (if possible) selected binaries, together with their assigns, paths and ENV checking (i.e. DHCP=true) if needed. Thanks to this you can for example:

arostcp.service stop

from your command line (if you set S bit and add services: to path).

7) And finally - I keep my AROSTCP binary in C:services, why not?

8) Thanks to the above I got rid of many messy assigns, paths and scripts...

So what do you think?

P.S. Oh - I forgot. I really DID move all amiga-style commmands to C: and all unix-style binaries to sys:gnu/bin (from whole wmvdistribution). Same with libraries. It really works as it should!