dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/20/88)
:In article <1877@iscuva.ISCS.COM>, ricks@iscuva.ISCS.COM (Rick Schaeffer)
: writes:
:> Most importantly, a shell spawned by CSH should inherit
:> it's parents environment.
:
:The problem is that for CLI programs there isn't a clear definition of what
1.3 has got enviroment variables. Guess how they're implemented!
Yup, disk based. You have a directory called ENV:, containing files
whos names are the enviroment variables and contents the contents for
those variables. Eventually, C-A says, ENV: will become a device.
(that device had better support Seek, Read, Write, Examine, ExNext,
etc... though, when it comes).
IT WORKS GREAT! I modified my shell to search ENV: for $ variables
and aliases and it gives 'global variables' a whole new meaning. If
you have a hard disk like I do, it is even better, because it takes
no memory at all, just a minor amount of disk space. If you've got
a cache (I don't at the moment) it is even better than better.
And, even better than better than better, the 'variables' can be
anything from a command-line type of thing to any type of file you
wish... IFF or whatever. Frankly, I think ENV: should stay in the
filing system. Amoung other things, you have a choice of making
it semi-permanent (put ENV: on your hard disk or floppy), or
temporary (put ENV: in RAM:). Making mine semi-permanent, I don't
have to re-load the enviroment every time I boot up!
-Mattpeter@sugar.uu.net (Peter da Silva) (08/20/88)
In article <8808192105.AA16960@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > :In article <1877@iscuva.ISCS.COM>, ricks@iscuva.ISCS.COM (Rick Schaeffer) [ talks about a process' environment ] [ I said: ] > :The problem is that for CLI programs there isn't a clear definition of what [ the environment is... ] > 1.3 has got enviroment variables. Guess how they're implemented! This is a classic example of how the UNIX terminology confuses things. What I mean, and what I thought Rick Schaeffer meant, is the whole environment of the shell: Current directory. Open files. Priority. Path. And so on... Environment variables, on the Amiga, aren't even part of the environment. They're global to the system as a whole... which causes even more confusion. As an aside, I like the way Commodore has set up the global system variables, but I think that they should really be stuck in CLIP:, so they can be flushed to disk when memory gets tight. What, you mean there isn't a CLIP:??? Before doing a real ENV:, do a CLIP: device and just map ENV: to it. What's a CLIP:? Simple... it's a device interface to the clipboards... -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
ricks@iscuva.ISCS.COM (Rick Schaeffer) (08/20/88)
In article <8808192105.AA16960@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > 1.3 has got enviroment variables. Guess how they're implemented! > > Yup, disk based. You have a directory called ENV:, containing files > whos names are the enviroment variables and contents the contents for > those variables. Eventually, C-A says, ENV: will become a device. > One suggestion...could CSH make a COPY of ENV: for any child it spawns? That way the child process could muck around with the environment...change paths... etc without affecting the parent. Maybe something like "ENV:CLIn/$var" where n is the process number (cli number) of the child and before calling the child you copy all of your environment into the new directory. That way you can STILL have a global environment ("ENV:$var") and each sub-process can have an environment of it's own. Add a couple of new commands: "gset" and "gunset" that work in the global environment and let "set" and "unset" work in the "local" environment. -- Rick Schaeffer UUCP: uunet!iscuva!ricks ISC Systems Corp. ricks@iscuva.ISCS.COM Box TAF-C8 Phone: (509)927-5114 Spokane, WA 99220
charles@hpcvca.HP.COM (Charles Brown) (08/21/88)
> 1.3 has got enviroment variables. Guess how they're implemented! > > Yup, disk based. You have a directory called ENV:, containing files > whos names are the enviroment variables and contents the contents for > those variables. Eventually, C-A says, ENV: will become a device. > -Matt How does this allow a child to have an environment different from its parent? Specifically grandparent | | parent1 parent2 | | child1 child2 I think Parent1 and parent2 should both inherit their environments from grandparent. They should then be free to modify those environments and pass them on to their children without interference from the other parent or other child. So Child1 should inherit from parent1 without interference from parent2 or from child2. It looks like the ENV: solution will have all of these processes writing to the same files and so all will share the same environment. Have I interpreted ENV: correctly? Charles Brown charles%hpcvca@hplabs.hp.com
jesup@cbmvax.UUCP (Randell Jesup) (08/22/88)
In article <5660008@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >How does this allow a child to have an environment different from its >parent? Specifically > > grandparent > | | > parent1 parent2 > | | > child1 child2 >It looks like the ENV: solution will have all >of these processes writing to the same files and so all will share the >same environment. Yup. If some program/shell needs locals they don't want have to worry about collision (i.e. it's going to change them, for example), then put use the CLI number of the process in the var name (or put them in a sub- directory of that name). If you are using subdirectories, don't forget to makedir them before writing the file, if doing it from a program. This may change if we ever do a real ENV: handler, but even then it won't hurt to makedir the directory. In reality, almost all uses of envirionment variables are to supply parameters and defaults to programs, like EDITOR. The commodore shell in 1.3 uses the ENV: variables for it's shell variables. Most CShell clones (like mine and I suspect Matt's) will use them, but search internal shell variables first, mirroring Unix shell var/env var semantics (mostly). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/22/88)
:How does this allow a child to have an environment different from its :parent? Specifically : : grandparent : | | : parent1 parent2 : | | : child1 child2 It doesn't, but nobody ever said the UNIX enviroment paradigm was the proper way to go. The UNIX handling of the enviroment screws me up often. This way, not only is there a single, GLOBAL enviroment, but you have the added advantage of not having multiple redundant copies lying around ... in fact, none of the enviroment is in memory if you assign ENV: to your floppy or hard disk. Neither are there limitations to the enviroment size... Individual enviroment variables can theoretically hold entire file's worth of data. The only plausable assumption one can really make is that enviroment variables contain ASCII (can we even do that?). -Matt
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (08/23/88)
In article <8808220455.AA27577@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >[ ...] in >fact, none of the enviroment is in memory if you assign ENV: to your floppy >or hard disk. [ ... ] The current implementation of this strikes me as a hack. ENV: is created in your Startup-Sequence. This means that if you boot up with an old floppy, or simply forget to create ENV:, any program that asks for it will pop up a "Please insert volume ENV in any drive you stupid klutz." 'SetEnv' is also little more than a front-end for 'copy * ENV:var'. Shouldn't ENV: be part of the standard start-up assigns, like LIBS: or L: or C:? Or am I getting in on this game too late? >The only plausable assumption one can really make is that >enviroment variables contain ASCII (can we even do that?). > Since the variables are, indeed, files, I don't think you can assume anything about a "variable's" contents. Binary environment variables could be fun, you know... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
shf@well.UUCP (Stuart H. Ferguson) (08/23/88)
From: dillon@CORY.BERKELEY.EDU (Matt Dillon) | :How does this allow a child to have an environment different from its | :parent? Specifically [specific example tree deleted] | It doesn't, [...] There is a way to do it, which is to have a subdirectory for each process in the tree. When a child process looks for a given context variable, it looks in its own subdirectory first, then, if it doesn't find the given variable, it looks in its parent's directory and so on. This gives inheritance behavior using a file-structured device and without duplication of data. There are a couple of added advantages to this method over the SetEnv interface. You can modify the context variables for a different process by changing files in its subdirectory. Also, subdirectories could stick around after the process exits so that when the same process starts up again, it goes back to having its context set up the way it was last time. | ... in | fact, none of the environment is in memory if you assign ENV: to your floppy | or hard disk. Having "environment" variables on recoverable media such as floppy or hard-disk or even rrd is really great since you don't need to do a long series of SetEnv commands in your startup, you can just do one Assign and your environment is the way you want it. Also, every change to your environment does not require editing your startup sequence; you just change the ENV: directory and the change is made permanently. It might be nice, however, to have an environment search path, so that permanent environment vars could be set up on hard disk, and temporary changes for the current shell could live on RAM:. Just an idea. | Neither are there limitations to the environment size... | Individual environment variables can theoretically hold entire file's worth | of data. The only plausable assumption one can really make is that | environment variables contain ASCII (can we even do that?). Why impose that constraint? IFF would be nice for ENV: files such as Workbench-Backdrop and Guru-Sound. :-) | -Matt -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)
charles@hpcvca.HP.COM (Charles Brown) (08/23/88)
>:How does this allow a child to have an environment different from its >:parent? Specifically >: >: grandparent >: | | >: parent1 parent2 >: | | >: child1 child2 > It doesn't, but nobody ever said the UNIX enviroment paradigm was the > proper way to go. > -Matt I change my paradigm when I see that the new one is clearly superior to the old one. This kind of change should not be made for trivial reasons, because it breaks lots of software. It is already more painful to port Unix software to the Amiga than it really needs to be because of small differences which are not any better, just different. One example is the file name system. Using ":" too indicate root is in no way superior to "/". Using "//" to indicate previous directory is in no way superior to "../". Yet these differences make transporting software (and brainware) more difficult. In fact, Amigados has a clear inferiority in that it cannot refer to current directory which Unix does with ".". So why was AmigaDos done this way? Well, just because... If Amiga is going to change the paradigm for envariables, how about something that IS superior? Define a global default set of envariables (like ENV:). Each parent can define any number of envariables which will then be inherited by its children. If the child accesses an envariable the parent did not define, it gets the global default. If the child modifies and envariable, the new value will then be passed on to the grandchild. The child is prevented from modifying (to the parent) any envariables defined by the parent. However, the child can still use envariables to pass info back to the parent (or anyone else) by modifying or creating a global envariable. The more AmigaDos deviates from other operating systems (especially when it does not provide significant advantage in the deviation) the more the Amiga will be ignored by commercial software developers, and the more the Amiga will become "just a niche computer". -- Charles Brown charles%hpcvca@hplabs.hp.com My employer is not responsible for my opinions. However, my employer is responsible for my paycheck. :-)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/24/88)
:created in your Startup-Sequence. This means that if you boot up with an :old floppy, or simply forget to create ENV:, any program that asks for it :will pop up a "Please insert volume ENV in any drive you stupid klutz." :'SetEnv' is also little more than a front-end for 'copy * ENV:var'. Huh? so either don't boot up with an old floppy, or take the time (a whole 30 seconds!) to add an assign ENV:. The hell, if you boot up under an old floppy you aren't even running 1.3, so what's the point? And, it seems to me that the system is giving you a second chance when it puts up that requestor: "Hey, this program is expecting to be run under 1.3 but you are running a 1.2 enviroment!"... so you pop up another shell, assign ENV:, and hit retry on the requester, then make the assign permanent in your startup-sequence or whatever. > Shouldn't ENV: be part of the standard start-up assigns, like LIBS: >or L: or C:? Or am I getting in on this game too late? Yah, you put it in your startup-sequence. What difference does it make if the system does it, or you do it? I have to reassign all those defaults anyway for my HD. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/24/88)
:There is a way to do it, which is to have a subdirectory for each :process in the tree. When a child process looks for a given context :variable, it looks in its own subdirectory first, then, if it doesn't :find the given variable, it looks in its parent's directory and so on. :This gives inheritance behavior using a file-structured device and :without duplication of data. There are *lots* of things you can do, but it requires a certain amount of sophistication on the programmer's part. What I meant to say is that giving some process a set of enviroment variables which are different from the parents is not something that is easily accomplished in a compatible way without much sophistication. For instance, if you ran an editor TWICE and want to give EACH a different enviroment, it requires a certain amount of sophistication. Too much to be worth it, I think. Sure, you can do it, but whos gonna want to do it? :There are a couple of added advantages to this method over the SetEnv :interface. You can modify the context variables for a different process :by changing files in its subdirectory. Also, subdirectories could stick :around after the process exits so that when the same process starts up :again, it goes back to having its context set up the way it was last :time. I agree. I like the idea of subdirectories in ENV: ... really only useful if a given application requires the use of sooooo many enviroment variables that it would clutter up the main directory, but there are definate advantages beyond that. :It might be nice, however, to have an environment search path, so that :permanent environment vars could be set up on hard disk, and temporary :changes for the current shell could live on RAM:. Just an idea. Right! How about this: Implement softlinks by allocating one of those precious protection bits! Make it mean 'softlink', where the contents of the comment field would then be the link path. It would be nice if somebody could hack the filesystem to do this automagically. :Why impose that constraint? IFF would be nice for ENV: files such as :Workbench-Backdrop and Guru-Sound. :-) : :| -Matt :-- : Stuart Ferguson (shf@well.UUCP) Oh yucc. I figure enviroment variables should be *easy* to manipulate. What we need is some distinction between IFF and a simple text string. How about this: An enviroment variable is broken up into two parts. (1) An enviroment text string terminated with a \0 (any number of newlines inbetween), (2) An IFF file. Thus, a variable which is ONLY IFF would simply have a 0 byte at the beginning of the file, and a variable which is ONLY A STRING would simply be that string (\0 termination not needed if no IFF file follows). Hmm.. may want to make that four 0 bytes (or N, max 4, to longword align the IFF header so access can be optimized). This would allow both unsophisticated (the majority of usage) and sophisticated (special case) usage of the enviroment. It would also allow a shell command called 'printenv' give useful information for IFF files, since those files might be preceeded by a comment (the text\0). -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/24/88)
:One example is the file name system. Using ":" too indicate root is
:in no way superior to "/". Using "//" to indicate previous directory
:is in no way superior to "../". Yet these differences make
Just a single slash '/' indicates the parent directory, and although
I agree with you that this is not compatible with UNIX, I LIKE it *much*
better than having to type '../'.
:transporting software (and brainware) more difficult. In fact,
:Amigados has a clear inferiority in that it cannot refer to current
:directory which Unix does with ".". So why was AmigaDos done this
:way? Well, just because...
Just becuase it ISN'T UNIX. Nobody said UNIX is the only way to
do it. I have had more problems transporting files between UNIX machines
than I ever had porting them to the Amiga. Little things like many UNIXs
support only 14 character file names. Oops.
And anyway, I never liked that fact that one had to specifically
check for and ignore '.' and '..' when scanning UNIX directories. I like
the fact that the parent specifier is NOT in the directory ("/"), and the
fact that the current directory specifier is NOT in the directory (""). Thus,
one does not have any special cases within the directory itself.
:If Amiga is going to change the paradigm for envariables, how about
:something that IS superior? Define a global default set of
:envariables (like ENV:). Each parent can define any number of
:envariables which will then be inherited by its children. If the
:child accesses an envariable the parent did not define, it gets the
:global default. If the child modifies and envariable, the new value
Of course, we have already discussed this to death but... The general
answer is YES it can be done, but must be implemented in the programming
of the software rather than in the system UNLESS we agree on a creating a
new 'user' library which contains the appropriate functions (and does all
of this automatically).
>when it does not provide significant advantage in the deviation) the
>more the Amiga will be ignored by commercial software developers, and
>the more the Amiga will become "just a niche computer".
Oh bull shit. The Amiga might very well remain "just a niche
computer" to the majority of the CS world, but it isn't going to be because
it isn't UNIX.
-Mattjimm@amiga.UUCP (Jim Mackraz) (08/25/88)
In article <6889@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
) Shouldn't ENV: be part of the standard start-up assigns, like LIBS:
)or L: or C:? Or am I getting in on this game too late?
It will be part of the standard. Especially after a few "Please insert
ENV:" requesters.
)>The only plausable assumption one can really make is that
)>enviroment variables contain ASCII (can we even do that?).
)>
) Since the variables are, indeed, files, I don't think you can assume
)anything about a "variable's" contents. Binary environment variables could
)be fun, you know...
Preferences is being reworked to be something of a combination of
it's current form and ENV:. ENV: will have its place. It will probably
be text, by convention. There will probably be no notification when
ENV: is changed, but can be when PREFS: is changed.
This is probably one standard that will have to wait until the PREFS:
spec if released.
One problem is avoiding the block overhead for very small files. This
doesn't happen in RAM:, though. There are several approaches under
consideration.
There will also be recommendations regarding non-shared configuration,
such as the phone book for a term program, so that different users on a
network can set personal configuration but share a copy of the executable,
and work on projects in the same directory.
(Guess where I read about THAT issue!)
)Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.charles@hpcvca.HP.COM (Charles Brown) (08/27/88)
>:There is a way to do it, which is to have a subdirectory for each >:process in the tree. When a child process looks for a given context >:variable, it looks in its own subdirectory first, then, if it doesn't >:find the given variable, it looks in its parent's directory and so on. >:This gives inheritance behavior using a file-structured device and >:without duplication of data. This sounds workable if the routines for doing this are provided as standard librarys. If you ask individual programmers to go thru that, there will be a lot of code that just does not work right. > For instance, if you ran an editor TWICE and want to give EACH >a different enviroment, it requires a certain amount of sophistication. >Too much to be worth it, I think. Sure, you can do it, but whos gonna >want to do it? If I didn't want to be able to do this I would not have brought it up. I think the flat ENV: approach is too limiting in a programming context. Isn't this one of the reasons BASIC fell into disrepute? All of its variables are flat. > Right! How about this: Implement softlinks by allocating one of >those precious protection bits! Make it mean 'softlink', where the contents >of the comment field would then be the link path. It would be nice if >somebody could hack the filesystem to do this automagically. That is an excellent idea! It should be done regardless of what is done with ENV:. > Oh yucc. I figure enviroment variables should be *easy* to >manipulate. What we need is some distinction between IFF and a simple >text string. How about this: I agree. I sometimes would like to be able to edit the environment using a text editor. ------------------------------------------------------------ >:transporting software (and brainware) more difficult. In fact, >:Amigados has a clear inferiority in that it cannot refer to current >:directory which Unix does with ".". So why was AmigaDos done this >:way? Well, just because... > Just becuase it ISN'T UNIX. Nobody said UNIX is the only way to >do it. I have had more problems transporting files between UNIX machines >than I ever had porting them to the Amiga. Little things like many UNIXs >support only 14 character file names. Oops. "Just because it isn't Unix" is a poor reason to be inferior. I also am not saying that Unix is the only way to do it. I am saying that as long as a we do not have a clearly superior mechanism, the mechanism should be copied from an existing system. Unix is just an example that I am familiar with. > And anyway, I never liked that fact that one had to specifically >check for and ignore '.' and '..' when scanning UNIX directories. I like >the fact that the parent specifier is NOT in the directory ("/"), and the >fact that the current directory specifier is NOT in the directory (""). Thus, >one does not have any special cases within the directory itself. This is an implementation detail that could have been done differently with little effort. I know of a Unix-like system which does not have actual . and .. entries in the directory. The path parsing code is modified to treat . and .. as keywords. >:If Amiga is going to change the paradigm for envariables, how about >:something that IS superior? ...... > Of course, we have already discussed this to death but... The general >answer is YES it can be done, but must be implemented in the programming >of the software rather than in the system UNLESS we agree on a creating a >new 'user' library which contains the appropriate functions (and does all >of this automatically). I just want my system to be powerful, fast, flexible, and easy to use. Is that too much to ask? (Sigh...) >>when it does not provide significant advantage in the deviation) the >>more the Amiga will be ignored by commercial software developers, and >>the more the Amiga will become "just a niche computer". > Oh bull shit. The Amiga might very well remain "just a niche >computer" to the majority of the CS world, but it isn't going to be because >it isn't UNIX. > -Matt I am not asking for Unix. I am asking for better. -- Charles Brown charles%hpcvca@hplabs.hp.com Definitely not representing my employer.
mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst ) (08/29/88)
In article <8808232121.AA28517@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >:Amigados has a clear inferiority in that it cannot refer to current >:directory which Unix does with ".". So why was AmigaDos done this >:way? Well, just because... > Hello Matt, I know that there is no current directory symbol in AmigaDOS BUT in many cases an empty pathname, i.e "", works like current_directory. You can test this with the COPY command, just COPY filename "" will copy 'filename' into your current directory. In your programs you can get a lock to the current directory by using yourprocess->pr_CurrentDir; or currentdir = CurrentDir(NULL); CurrentDir(currentdir); or currentdir = Lock(""); !!!!!!!!!!!!!(don't forget to UnLock :-) Michael van Elst E-mail: UUCP: ...seismo!unido!fauern!faui44!mlelstv E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv <- when seismo ceases operation
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/31/88)
:In article <8808232121.AA28517@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
:>:Amigados has a clear inferiority in that it cannot refer to current
:>:directory which Unix does with ".". So why was AmigaDos done this
:>:way? Well, just because...
:>
:Hello Matt,
:
:I know that there is no current directory symbol in AmigaDOS BUT
:in many cases an empty pathname, i.e "", works like current_directory.
Uh, you got the wrong guy. I DIDN'T WRITE THAT! I *included* that
comment by somebody else in my on reply which stated exactly what you are
stating. The -other guy- also mentioned that AmigaDOS had a weird way of
going back to the parent directory and I pointed out that AmigaDOS's way
was a hell of a lot less weird than the UNIX way ('/' instead of '../').
Hello Mike,
-MattJeffrey_J_Vanepps@cup.portal.com (08/31/88)
[] They're doing an environment on the file system?! I always thought the main advantage of something called an "environment" over startup or configuration files was that it did NOT have to deal with the SLOW file system (i.e. the environment was memory-resident). Even MS-DOG saw that!
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/01/88)
>[] > >They're doing an environment on the file system?! I always thought the >main advantage of something called an "environment" over startup or >configuration files was that it did NOT have to deal with the SLOW >file system (i.e. the environment was memory-resident). Even MS-DOG >saw that! No, MS-DOG didn't see that... they never thought of it, and then screwed up their own implementation. Really... I am using it extensively and it works great! Remember that for most applications enviroment variables are not accessed extensively... for instance, an application might get an enviroment variable to figure out what FONT to use, or for some default or other. Even if it took an entire second to access the variable (which it doesn't.. about 1/20 sec from an HD, faster from RAM:) it would still be acceptable. Well, perhaps I am exaggerating a bit, but I have yet to experience speed-related problems with ENV:... and damn it, it is *NICE* not having to set them up every time I log in.. they're part of the filesystem. * Chit To Developers * USE ENVIROMENT VARIABLES! For instance, future releases of DME will check ENV: for the 'DMEFONT' to use, etc... Maybe programs should save back their window arrangement info to the ENV: under their own name so when we re-start applications they come up where we left off (at least in arrangement, settings, etc...)! That is one thing about that Mac I really like, which is sooooo simple to implement on the Amiga. And it makes sense too. I like to think of 'resources' as being more permanent than ENV:, and it makes more sense to save 'current settings' into ENV: rather than back into the (yet to be conceived) resource... makes HD backups more efficient. -Matt
thad@cup.portal.com (09/01/88)
And there's also the assignation trick:
CLI> assign here: ""
CLI> cd <elsewhere>
CLI> cd here:
that second CD returns one to the original directory in which the ASSIGN
was performed. This is very useful in EXECUTE scripts.jesup@cbmvax.UUCP (Randell Jesup) (09/01/88)
In article <8588@cup.portal.com> Jeffrey_J_Vanepps@cup.portal.com writes: >They're doing an environment on the file system?! I always thought the >main advantage of something called an "environment" over startup or >configuration files was that it did NOT have to deal with the SLOW >file system (i.e. the environment was memory-resident). Even MS-DOG >saw that! Except that the file system in use is RAM: (ramdisk). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
michael@stb.UUCP (Michael) (09/02/88)
In article <8808232121.AA28517@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >:One example is the file name system. Using ":" too indicate root is >:in no way superior to "/". Using "//" to indicate previous directory >:is in no way superior to "../". Yet these differences make > > Just a single slash '/' indicates the parent directory, and although >I agree with you that this is not compatible with UNIX, I LIKE it *much* >better than having to type '../'. Wrong. A single slash does NOT indicate the parent directory. This is the Amiga's file system problem--the symbols are context sensitive. The truth: A colon followed by a slash may be an error (is it assigned to a subdir?) N+1 non-initial consecutive slashes refers to N parents N initial slashes refers to N parents There is no easy way to take the name of a directory and append a file name to it. Tell you what: You give me a routine that will take two names, one a directory, one a file, and return me a pathname for the file. Handle ending slashes, null directories, assigned devices, assigned directories, files beginning with slashes, etc. AND make it usable in CLI scripts. Then, I will consider the Amiga's file system naming useably clean. (under non-v7 unix, this routine is arg1 + "/" + arg2. V7 allowed "" for current directory, so it would be (*arg1 == 0? "./" : arg1 + "/") + arg2 (+ == strcat)) : --- : Michael Gersten uunet.uu.net!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : Coff Coff <=== Stop smoking.
jdow@gryphon.CTS.COM (J. Dow) (09/02/88)
In article <8588@cup.portal.com> Jeffrey_J_Vanepps@cup.portal.com writes: >[] > >They're doing an environment on the file system?! I always thought the >main advantage of something called an "environment" over startup or >configuration files was that it did NOT have to deal with the SLOW >file system (i.e. the environment was memory-resident). Even MS-DOG >saw that! Temporary measure until it gets done right as an update. The user interface will remain the same or so the intention goes. -- Sometimes a bird in the hand leaves a sticky deposit. Perhaps it were best it remain there in the bush with the other one. {@_@} jdow@bix (where else?) Sometimes the dragon wins. Sometimes jdow@gryphon.CTS.COM the knight. Does the fair maiden ever {backbone}!gryphon!jdow win? Surely both the knight and dragon stink. Maybe the maiden should suicide? Better yet - she should get an Amiga and quit playing with dragons and knights.
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/03/88)
In article <8637@cup.portal.com> thad@cup.portal.com writes: > CLI> assign here: "" > CLI> cd <elsewhere> > CLI> cd here: > >that second CD returns one to the original directory in which the ASSIGN >was performed. This is very useful in EXECUTE scripts. ... scripts which are not meant to support multitasking, that is. If you were to run that same script in another window in the meantime, the "here:" assign would be lost. Of course, it wouldn't be the first Amiga program with this problem. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
stellrec@deneb.cis.ohio-state.edu (barry stellrecht) (09/03/88)
[ line eater fodder ] In article <4653@cbmvax.UUCP> :In article <8637@cup.portal.com> thad@cup.portal.com writes: :> CLI> assign here: "" :> CLI> cd <elsewhere> :> CLI> cd here: :> :>that second CD returns one to the original directory in which the ASSIGN :>was performed. This is very useful in EXECUTE scripts. :... scripts which are not meant to support multitasking, that is. If you :were to run that same script in another window in the meantime, the "here:" :assign would be lost. Of course, it wouldn't be the first Amiga program :with this problem. :-- : -=] Ford [=- : . . (In Real Life: Mike Ditto) :. : , ford@kenobi.cts.com A way which supports multi-tasking much better, if you are using the Dillon/ Drew CSH program would involve the two aliases below (I use them fairly extensively myself): alias savecd "cd | input _oldcd" alias oldcd "cd $_oldcd;unset oldcd" Usage might be like: savecd;cd telecom:; {do stuff} oldcd. I find them quite nice for quickly booting up programs that like their own directory for stuff, without getting my working directory somewhere other than where I want it Barry Stellrecht
bryan@cs.utexas.edu (Bryan Bayerdorffer) (09/04/88)
In article <21291@tut.cis.ohio-state.edu> stellrec@deneb.cis.ohio-state.edu (barry stellrecht) writes: =-A way which supports multi-tasking much better, if you are using the Dillon/ =-Drew CSH program would involve the two aliases below (I use them fairly =-extensively myself): =- =-alias savecd "cd | input _oldcd" =-alias oldcd "cd $_oldcd;unset oldcd" =- It's faster and more elegant to use an alias with argument substitution than to use a pipe. I.e. alias savecd "%z cd $z; set _oldcd $z" In any case, the following is a much more general solution. I don't remember who first came up with this, but it wasn't me: # push and pop directories alias pop "strhead _cwd ~ $popdir ; strtail popdir ~ $popdir ; cd >NIL: $_cwd ;$alias push "%q set popdir $_cwd~$popdir ; cd $q" Nice, huh? Other shell quirkinesses (or, I call 'em bugs, you call 'em features): strhead b \ $a #will correctly break $a at a space, but... strhead b \ $a #will not. The 'input' command does not abort at an end-of-file (^\). ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___ |____Teachers leave the kids alone__|_____|_____|_____|_bryan@cs.utexas.edu___| ___|_____|_____|_____|_____|_____|_____|{ihnp4,seismo,...}!cs.utexas.edu!bryan_ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
jesup@cbmvax.UUCP (Randell Jesup) (09/04/88)
In article <10580@stb.UUCP> michael@stb.UUCP (Michael) writes: >A colon followed by a slash may be an error (is it assigned to a subdir?) It is an error. >N+1 non-initial consecutive slashes refers to N parents >N initial slashes refers to N parents It's all a matter of how of how you tokenize (in your mind or otherwise) the pathname. If you (in your mind) include the / at the end of a directory name, it makes sense. Think of walking through the path left to right, handling it as you go. >There is no easy way to take the name of a directory and append a file > name to it. Define easy. >Tell you what: You give me a routine that will take two names, one a >directory, one a file, and return me a pathname for the file. Handle >ending slashes, null directories, assigned devices, assigned directories, >files beginning with slashes, etc. AND make it usable in CLI scripts. >Then, I will consider the Amiga's file system naming useably clean. ok char *foo (char *dir,char *file) { /* I assume dir can be extended here */ int dirlen = strlen(dir); char lastchar; if (dirlen) { lastchar = dir[dirlen-1]; if (lastchar != ':' && lastchar != '/') strcat(dir,"/"); } strcat(dir,file); return dir; } It can be much more efficient, but I wrote for clarity. As for "use in shell scripts", I don't understand you at all. Which shell, used how? AmigaDos CLI, AmigaDos Shell (1.3), Dillon's shell, TShell, Wsh, something else? File _names_ cannot have slashes in them (by definition). >(under non-v7 unix, this routine is arg1 + "/" + arg2. V7 allowed "" for >current directory, so it would be (*arg1 == 0? "./" : arg1 + "/") + arg2 >(+ == strcat)) It's more complicated than unix, but then it supports removable media better than Unix does, and I (for one) find it easier to deal with than typing 3 characters per directory up, instead of one. This is especially true when combined with a shell that does an implicit cd when you type a directory name. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/04/88)
:> Just a single slash '/' indicates the parent directory, and although :>I agree with you that this is not compatible with UNIX, I LIKE it *much* :>better than having to type '../'. : :Wrong. A single slash does NOT indicate the parent directory. This is the :Amiga's file system problem--the symbols are context sensitive. Look guy, if you just *THINK* about it you will find that the UNIX ../ can be replaced *exactly* by a single slash: UNIX AMIGA ../x/y /x/y x/../y x//y :The truth: :A colon followed by a slash may be an error (is it assigned to a subdir?) Sure, if you are in the root directory of the device you can't go back. If not (an assigned subdir), you can. So what is the problem? :N+1 non-initial consecutive slashes refers to N parents :N initial slashes refers to N parents :There is no easy way to take the name of a directory and append a file : name to it. What are you talking about? :Tell you what: You give me a routine that will take two names, one a :directory, one a file, and return me a pathname for the file. Handle :ending slashes, null directories, assigned devices, assigned directories, :files beginning with slashes, etc. AND make it usable in CLI scripts. :Then, I will consider the Amiga's file system naming useably clean. What are you talking about? I do this all the time. I don't see how it can be done in UNIX any easier than on the Amiga. ending slashes in UNIX: UNIX allows you to have multiple slashes in a filename (at least, 4.3 BSD does). A/B is equivalent to A//B ... Most people, however, do not consider A//B to be of correct form. On the Amiga, this UNIX-hack is obviously not implemented because the Amiga is more sensible in its solution. null directories I understand. I don't see how assigned devices enters in to it because UNIX doesn't support multiple filesystem roots. Files beginning with slashes? you mean when you specify part of a directory path in the filename? Come on, this is *easy*. Every filerequester in existance does this. You could write it in 1 minute. Now this last part 'usable in CLI scripts'... strange condition. Frankly, the relative merits of the CLI's language being able to support the above algorithm efficiently enough has absolutely no bearing on the merits of the filesystem unto itself. >(under non-v7 unix, this routine is arg1 + "/" + arg2. V7 allowed "" for >current directory, so it would be (*arg1 == 0? "./" : arg1 + "/") + arg2 >(+ == strcat)) Since you are so fond of C, I shall simply outline the routine and let you write it: Assumptions: Assume the two parts (dir and file) are to be considered independant paths in their own right. I.E. if dir ends in a '/' we are specifying the parent directory of something. If you don't like that last assumption, then simply replace "not ':'" with "not ':' and not '/'" in the two line routine below... that is, allow for the 'dumb user' who puts extranious characters in his path specifications. Routine (dir, file) { If dir != "" && last char of dir is not ':', append a '/' to dir Return (dir + file) } Gosh, that was easy. Now if you want to handle other cases, like the 'file' isn't just a filename, but an entire path, that's ok with me... you would add something like "If file contains a ':' then ignore dir". This handles: (1) ending slashes on the dir part (assumes you mean go to parent after resolving rest of dir OR assumes user added extranious char). (2) null directories, (3) assigned devices & dirs (:), (4) files beginning with one or more slashes (assumes you want to go to the N'th parent.. why else put a slash in front of a filename?). (5) usable in CLI scripts?? What kind of condition is this? Just write it in C and provide it as a CLI command. -Matt
vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) (09/05/88)
In article <4660@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > [somebody else writes] : :Tell you what: You give me a routine that will take two names, one a : :directory, one a file, and return me a pathname for the file. Handle : :ending slashes, null directories, assigned devices, assigned directories, : :files beginning with slashes, etc. AND make it usable in CLI scripts. : :Then, I will consider the Amiga's file system naming useably clean. : : ok : : char *foo (char *dir,char *file) : { : /* I assume dir can be extended here */ : int dirlen = strlen(dir); : char lastchar; : : if (dirlen) { : lastchar = dir[dirlen-1]; : if (lastchar != ':' && lastchar != '/') : strcat(dir,"/"); : } : strcat(dir,file); : return dir; : } : : It can be much more efficient, but I wrote for clarity. Then sombody with nothing better to do will come along and do 'foo("df0", "fi");' and get "df0/fi" and start yelling. The problem is that only the OS knows what are the legal device names. Now ARP has exactly such a routine. But I don't know if it will take all the abuse you can heap on
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/05/88)
:Then sombody with nothing better to do will come along and do
:'foo("df0", "fi");' and get "df0/fi" and start yelling.
:The problem is that only the OS knows what are the
:legal device names.
That is plain stupid. If you want DF0: you SAY DF0:, if you want
a subdirectory called df0, you SAY df0... Not even an idiot would specify
DF0: as DF0 without the colon. I mean, come on now... how about some
practical arguments.
-Mattthad@cup.portal.com (09/05/88)
Mike Ditto brings up a good point re: my example of ``ASSIGN HERE: "" '' Been doing the same thing on multi-tasking/multi-user mainframes for over 2 decades, HOWEVER ... - on the mainframes, the assigns were LOCAL to a process - on the Amiga, the assigns are GLOBAL to the system A workaround would be to append the CLI process number to the "here:" (e.g. HERE1:, HERE2:, etc.). Just another one of those thingies that works "only" 99.94% of the time! :-) Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
keithd@cadovax.UUCP (Keith Doyle) (09/07/88)
In article <8637@cup.portal.com> thad@cup.portal.com writes:
.And there's also the assignation trick:
.
. CLI> assign here: ""
. CLI> cd <elsewhere>
. CLI> cd here:
.
.that second CD returns one to the original directory in which the ASSIGN
.was performed. This is very useful in EXECUTE scripts.
Just don't try it in Execute(), or you'll end up at DF0: no matter where
you started from. (BTW, is this fixed in 1.3?)
Keith Doyle
# {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170charles@hpcvca.HP.COM (Charles Brown) (09/07/88)
> :Then sombody with nothing better to do will come along and do > :'foo("df0", "fi");' and get "df0/fi" and start yelling. > :The problem is that only the OS knows what are the > :legal device names. > > That is plain stupid. If you want DF0: you SAY DF0:, if you want > a subdirectory called df0, you SAY df0... Not even an idiot would specify > DF0: as DF0 without the colon. I mean, come on now... how about some > practical arguments. > -Matt Calm down Matt! Your statement is not quite true. Shall we make a list of standard Amiga commands which require the : name be specified without the colon? Start with Format. Granted MyDisk: is not exactly the same as DF0: but it sure looks like the same format. Be careful who you call an idiot. -- Charles Brown
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/08/88)
>Calm down Matt! Your statement is not quite true. Shall we make a >list of standard Amiga commands which require the : name be specified >without the colon? Start with Format. Granted MyDisk: is not >exactly the same as DF0: but it sure looks like the same format. >Be careful who you call an idiot. >-- >Charles Brown Uh, I don't see how your comment fits into the argukment. I assume you are thinking of the following line: Format drive DF0: name "MyDisk" And while MyDisk doesn't have a colon in it, one should also note that the reference is not to a volume anyway, but the naming of a disk which has yet to exist (i.e. it will eventually become a volume). Besides, Format is a *very* specialized and special-case command. Come on, Give me a break! -Matt
charles@hpcvca.HP.COM (Charles Brown) (09/09/88)
> I assume you are thinking of the following line: > Format drive DF0: name "MyDisk" Yes. > And while MyDisk doesn't have a colon in it, one should also > note that the reference is not to a volume anyway, but the naming of a > disk which has yet to exist (i.e. it will eventually become a > volume). Besides, Format is a *very* specialized and special-case > command. I think you are splitting hairs. I have to remember to omit the colon here but use it most other places. That is not intuitive. Format could have stripped off a trailing colon if it was there. (CBM: This could still be done to Format in the next AmigaDos without breaking anything. Hint! Hint!) > Come on, Give me a break! > -Matt I am not trying to give you a hard time. I am impressed by the programming you have done. However, your comment implied that any program that (and by extension anyone who) confuses exactly when to use a colon must be stupid. I have been bit by Format over exactly this problem. I do not consider myself stupid. So... Give ME a break. Charles
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/10/88)
>I am not trying to give you a hard time. I am impressed by the >programming you have done. However, your comment implied that any >program that (and by extension anyone who) confuses exactly when to >use a colon must be stupid. I have been bit by Format over exactly >this problem. I do not consider myself stupid. >So... Give ME a break. > Charles Well, you could at least use a better example.... I've *never* been bit by Format, but I have been bit by ReLabel.... but since I got the wrong results using the colon on the new volume name it was obvious I had to omit the colon.... Even so, these meager special-case examples are hardly enough reason to go changing (or complaining) about the filesystem naming conventions. UNIX is not without its quirks either... for instance, having to ignore the '.' and '..' entries when traversing directories. Having to check for and ignore (sometimes) softlinks, having to worry about non-files (devices) and other things.... It builds up! -Matt
bader+@andrew.cmu.edu (Miles Bader) (09/13/88)
vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) writes: > Then sombody with nothing better to do will come along and do > 'foo("df0", "fi");' and get "df0/fi" and start yelling. > The problem is that only the OS knows what are the > legal device names. Huh? "df0/fi" is the correct result... I don't want the OS deciding something is a device when I specify a directory. MSDOS does this (try saving "con.bas" from basic), and it's really irritating. If someone starts yelling about something out of ignorance, they should be straightened out, not listened to. -Miles
jesup@cbmvax.UUCP (Randell Jesup) (09/14/88)
In article <8X=3WTy00Vs4ECYvw-@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) writes: >> Then sombody with nothing better to do will come along and do >> 'foo("df0", "fi");' and get "df0/fi" and start yelling. >> The problem is that only the OS knows what are the >> legal device names. > >Huh? "df0/fi" is the correct result... I don't want the OS deciding >something is a device when I specify a directory. MSDOS does this >(try saving "con.bas" from basic), and it's really irritating. Correct. It is prefectly valid to have a directory named df0. Nothing is a device name UNLESS it has a ':' at the end. Being upset about the about is equivalent to being upset that when you say "bin/xyzzy" it looks relative to your current directory, instead of in /bin/xyzzy. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup