Thanks to Tom and Adriaan, my compiler in in order on Mac OSX (but before trying to load the Developper Tools CD from USA1 and not from Europa, I was desesperate). Yet, other problems are coming...
1) 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 ? 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 ?
2) 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)
Thanks in advance, Dominique
On Tuesday 09 September 2003 09:00, you wrote:
Thanks to Tom and Adriaan, my compiler in in order on Mac OSX (but before trying to load the Developper Tools CD from USA1 and not from Europa, I was desesperate). Yet, other problems are coming...
- 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 ? 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 ?
Some checks questions on 1a: * The shell has to know the new PATH, either by restarting or by rereading the rc file using the command "source ~/.tcshrc" * Is the PATH variable not overwritten by other resource files? See the man page of tcsh (I cut and paste for your convenience:)
\begin{cut}
Startup and shutdown A login shell begins by executing commands from the system files /etc/csh.cshrc and /etc/csh.login. It then executes commands from files in the user’s home directory: first ~/.tcshrc (+) or, if ~/.tcshrc is not found, ~/.cshrc, then ~/.history (or the value of the histfile shell variable), then ~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell variable) (+). The shell may read /etc/csh.login before instead of after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or ~/.cshrc and ~/.history, if so compiled; see the version shell variable. (+)
Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on startup.
For examples of startup files, please consult http://tcshrc.source-forge.net.
\end{cut}
For 1b, I think the following extract of a tcsh-script of mine might be sufficient:
setenv SWITCHES "-g -pg --progress-messages --automake -O2 " setenv TARGETSTUFF " --unit-destination-path=obj/obj_fem --executable-file-name= bin/charles " setenv UNITPATH firstunitdir:secondunitdir setenv UNITPATH ${UNITPATH}:thirdunitdir
gpc $SWITCHES $TARGETSTUFF $UNITPATH charles.p
Here UNITPATH points to the directories where the source files of the units used are located. I think automake does a good job checking what of those has to be updated, if required.
For the export problem, I do not know. Anyone else?
Regards,
Marten Jan
- 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)
Thanks in advance, Dominique
DOMINIQUE THILLAUD wrote:
[snip]
- 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)
Extended Pascal's export-part is based on identifier spellings only which doesn't really work well with the PASCAL SC operator overloading extension which is based on operator symbols and operand type signatures. Since +, -, *, and / are operator symbols and not identifiers, there is no explicit identifier spelling for overloaded operators available for usage in an explicit export-list.
GPC does have an export all extension which doesn't require explicit lists of identifier spellings which implicitly imcludes everthing defined in the interface-part/module-heading in the exported interface. Thus:
export rationals = all;
will, I think, implicitly include interface defined operators (e.g. +, -, etc.) in the exported rationals interface.
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.
Gale Paeper gpaeper@empirenet.com
On 9 Sep 2003 at 9:00, DOMINIQUE THILLAUD wrote:
Thanks to Tom and Adriaan, my compiler in in order on Mac OSX (but before trying to load the Developper Tools CD from USA1 and not from Europa, I was desesperate). Yet, other problems are coming...
- 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 ?
Depends on which shell you are using. But a quick way to do this from the command line is: export PATH=.:$PATH
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 ?
With more recent gpc snapshots, use the "GPC_UNIT_PATH" environment variable - e.g., export GPC_UNIT_PATH=$HOME/foo:$HOME/bar:$HOME/pascal/blah
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
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
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
John Ollason wrote:
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?
(It is off topic, and kind of a Unix FAQ. Actually, it's not strictly limited to Unix -- the same will probably apply when using a shell on a multi-user, say Mac OS or Windows, system.)
The problem is that a local attacker can place a malicious program under a common name (ls, dir, or whatever) in a world-writable directory such as /tmp. So when you're in that directory and enter this command with . in your $PATH, you will execute the malicious program (which then can, of course, do anything in your name and give the attacker almost unlimited control of your account).
BTW, what I do for GPC programs (to remain a little on-topic) is to place the executables in a fixed directory (--executable-path=$HOME/bin, or whichever directory you prefer) and put that directory (which is, of course, only writable by me, and with an absolute directory name) in my $PATH. Apart from the problem with ., it also prevents executables from lying around in various working directories.
Frank
Le Mercredi 10 Septembre 2003 21:46, John Ollason a écrit :
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?
Yes when . is in the path, it is much easier for a hacker to set up a trojan program. It is specially easy if you have a directory writable by others (group-writable or world-writable): putting in this directory a program named ls (just an example, there is nothing magic about ls, it is just something used quite often and looking quite safe) is enough: when the other-writable is the current directory, if you type ls (and you will do it some day, it is just a question of time) you will not use the true ls but the hacked one ... and only Satan and Belzebuth know what will happen. This is the crudest, and most usual, attack, it does not need any technical expertise; there are others, more complicated. See chapter one of any book on unix security.