Greetings, everybody,
I am just an ordinary user who has used UN*X operating systems on Suns since the dawn of time. I have _always_ set . in my path in the login script in my accounts on my linux machines. Indeed it has always been present in the standard login scripts provided to the average user on the machines on which I have had accounts. After frying one of the lib files with a frivolous update that went wrong I once had to crank up sash to replace the file and I was stalled for ages until I remembered that I had to be explicit about the current working directory. So, what's the problem? Have I been juggling with running chainsaws all these years?
John O. --------
On Tue, 9 Sep 2003, Frank Heckenbach wrote:
DOMINIQUE THILLAUD wrote:
- PATH problems
1a) I'm unable to execute the a.out (nor the hello if using -o) directly but must use the stupid ./a.out (or ./hello). Even if I redefine the variable PATH in ~/.tcshrc (adding to it the current directory .). Where lies the file who defines PATH ?
See other's replies. However, I suggest not to do it. Even if you're on a single-user system now, you might be using a multi-user system sometimes, and it's good not to get used to having . in the PATH which would then be a real security hole.
1b) I construct some modules for toolboxes (like timer.p) or for abstract types (like lists.p) and I would like to put them in a genuine directory such that the compiler could find them from any other directory : how do it ?
--unit-path
- export problem
If I construct a module to implement an abstract type such that rational numbers, how export operators ? Writing : export rationals = (rational, +, -, *, /) ; give me a parse error before '+' (trying to enclose + between ' ' or " " is useless)
Gale Paeper wrote:
Internally, GPC creates mangled function names for user defined/overloaded operators. The mangling scheme is based, I think, on a textual spelling of the operator symbol (e.g., PLUS for +) and the operand parameter type identifier(s). If one absolutely needs more control over what's included in an exported interface than what export all provides, determining what an operator's mangled function name is and then using the mangled name in the export-list might work. (I haven't tried this.) I wouldn't try to make use of this, though, unless you deparately must have something more selective than export all since it ties your code to changeable internal compiler details, is error prone, and has a lot of negative code maintenance implications.
It won't work anyway (intentionally, since these internal identifiers are designed not to conflict with the internal representation of regular identifiers).
So `export = all' (or, using a unit which is the same in this regard) is the only way.
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707