sansom@trwrb.UUCP (06/05/87)
It appears as if Gulam doesn't set the current directory (or path) as far
as GEMDOS is concerned. Last night, I wrote a simple program which reports
the current working directory using Dgetpath(). No matter which directory
Gulam thinks I'm in, the program reports the current path as "\bin" (which
happens to be the directory in which Gulam resides). On the other hand,
when I execute a GEM application, the application picks up Gulam's idea of
the current directory. Does Gulam only do a Dsetpath() when it executes
a GEM program?
Here's another one: when I left my Gulam session last night, I returned to
a desktop which was composed of alpha-numeric characters instead of
bit-mapped graphics! Everything seemed to be in its correct location on
the screen, but the menu bar was composed of a bunch of "|"s, the windows
were rectangularly shaped arrangements of "b"s, "|"s, and the regular
close and full characters, and the drive and trash can icons were a mixture
of other characters. Interestingly enough, I was still able to select, and
even execute programs using the mouse (although I couldn't read what I was
selecting).
Could this possibly be related to my experiments with Dget/setpath()? It
was late, so I didn't try to recreate the problem. Has anyone else out
there come across this beauty? Any ideas?
-Rich
--
/////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/// Richard E. Sansom TRW Electronics & Defense Sector \\\
\\\ {decvax,ucbvax,ihnp4}!trwrb!sansom Redondo Beach, CA ///
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////billw@wolf.UUCP (06/06/87)
While on the subject, another trifling but VERY annoying problem exists with
ue in gulam. It seemd to think all pathnames are relative, not absolute. When
I am in bin and try to ue \src\ts.c, for example, ue puts me into a 'new file'
buffer with the pathname \bin\\src\ts.c. I hope this is repaired in a forth-
coming version...
--
Bill Wisner
..{sdcsvax,ihnp4}!jack!wolf!billwbammi@cwruecmp.UUCP (06/08/87)
In article <1942@trwrb.UUCP> sansom@trwrb.UUCP (Richard Sansom) writes: >It appears as if Gulam doesn't set the current directory (or path) as far >as GEMDOS is concerned. Last night, I wrote a simple program which reports >the current working directory using Dgetpath(). No matter which directory >Gulam thinks I'm in, the program reports the current path as "\bin" (which >happens to be the directory in which Gulam resides). On the other hand, >when I execute a GEM application, the application picks up Gulam's idea of >the current directory. Does Gulam only do a Dsetpath() when it executes >a GEM program? Strangeness! I just checked the source and Gulam does indeed do both a Dsetdrv() and a Dsetpath() when it executes the 'cd' command. In fact Gulam never maintains an internal path. When you do a 'pwd' it does a Dgetdrv() and a Dgetpath()) makes up a string and reports that to you. After doing a 'cd' it does an internal getpwd() to set the variable $cwd. I tried the following from within Gulam and it always reported the correct path, no matter where i cd'ed to. (When you exit Gulam via 'exit', it cd's to $home and exits). #include <stdio.h> #include <osbind.h> main() { char cwd[128]; cwd[0] = Dgetdrv() + 'a'; cwd[1] = ':'; Dgetpath(&cwd[2], 0); if (cwd[2] == '\000') {cwd[2] = '\\'; cwd[3] = '\000';} printf("%s\n", cwd); } >Here's another one: when I left my Gulam session last night, I returned to >a desktop which was composed of alpha-numeric characters instead of >bit-mapped graphics! Everything seemed to be in its correct location on >the screen, but the menu bar was composed of a bunch of "|"s, the windows >were rectangularly shaped arrangements of "b"s, "|"s, and the regular >close and full characters, and the drive and trash can icons were a mixture >of other characters. Interestingly enough, I was still able to select, and >even execute programs using the mouse (although I couldn't read what I was >selecting). > Sounds like something went and overwrote some Gem areas. Maybe all this was due to Gulam running out of memory and creating havoc in the system!! We will have a fuller report on Gulam's memory problems here soon. Some of them have been caught since the posting here. There are probably others! -- usenet: {decvax,cbatt,cbosgd,sun}!cwruecmp!bammi jwahar r. bammi csnet: bammi@cwru.edu <---------Please note change of address arpa: bammi@cwru.edu <---------Please note change of address compuServe: 71515,155
bammi@cwruecmp.UUCP (06/08/87)
In article <412@wolf.UUCP> billw@wolf.UUCP (Bill Wisner) writes: >While on the subject, another trifling but VERY annoying problem exists with >ue in gulam. It seemd to think all pathnames are relative, not absolute. When >I am in bin and try to ue \src\ts.c, for example, ue puts me into a 'new file' >buffer with the pathname \bin\\src\ts.c. I hope this is repaired in a forth- >coming version... pm@cwru.edu probably has a better explaination for this decisions, but as i recall this 'feature' is an emulation of the behavior of GnuEmacs, where when you try to visit-file, it always puts the $cwd of the current buffer in for you. The diff is that in GnuEmacs if you then type in an absolute path (starting with a '/'), it will drop the $cwd prefix, and visit-file the file whose absolute path name you specify. Perhaps this should be the behavior of 'ue' too. Currently the best way i guess is to kill-backward-word (by default bound to ESC DEL) to get rid of the $cwd prefix and then type in the file name (remember that file-name-completion works here too!). I do agree that it is annoying. -- usenet: {decvax,cbatt,cbosgd,sun}!cwruecmp!bammi jwahar r. bammi csnet: bammi@cwru.edu <---------Please note change of address arpa: bammi@cwru.edu <---------Please note change of address compuServe: 71515,155