mcdonald@aries.scs.uiuc.edu (Doug McDonald) (08/06/90)
I am having a problem with Fortran under Unix, to be specific, the f77
compiler that comes for a Mips 120. I need to have a prompt on one
line with the user's typed input on the same line. In VMS Fortran,
and all the Fortrans I have on my IBM PC, using the following works:
write(*,100)
100 format(/,' >',$)
read(*,101)a
101 format(70a1)
The $ is not a standard F77 feature. Yet it IS documented to do what
I want in the Mips Fortran manual. It doesn't work: I have to type
two carriage returns to get input, which comes in wrong.
How does one do this in Mips Fortran, or in general on common Unix Fortrans.
P.S. This may or may not matter - I am logged in over a Telnet connection.
The world and comp.sources.games is anxiously awaiting an answer :-)
Doug McDonald (mcdonald@aries.scs.uiuc.edu)rogerk@mips.COM (Roger B.A. Klorese) (08/14/90)
In article <1990Aug5.192922.20989@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >The $ is not a standard F77 feature. Yet it IS documented to do what >I want in the Mips Fortran manual. It doesn't work: I have to type >two carriage returns to get input, which comes in wrong. > >How does one do this in Mips Fortran, or in general on common Unix Fortrans. This is a bug in Mips Fortran releases 1.31 and 2.0. Upgrade to release 2.10 (if you are running pre-4.50 RISC/os) or 2.11 (for 4.50). -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 MS 4-02 950 DeGuigne Dr. Sunnyvale, CA 94086 voicemail: +1 408 524-7421 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I'm the NLA" "If the world were a logical place, men would ride sidesaddle." -Rita Mae Brown
bguthy@amazon.eecs.umich.edu (Bala S. Guthy) (02/22/91)
Hello, I remember when I first learnt Unix, the instructor said, that "." should never be the first thing in one's $path. It had something to do with a security hole in Unix. Does anyone know what and if there is any disadvantage to having "." as the first entry in $path. Thank you. v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v | | | Bala S. Guthy aktca bguthy@eecs.umich.edu | | | ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
gwyn@smoke.brl.mil (Doug Gwyn) (02/23/91)
In article <1991Feb22.004010.13359@zip.eecs.umich.edu> bguthy@amazon.eecs.umich.edu (Bala S. Guthy) writes: >Hello, I remember when I first learnt Unix, the instructor said, >that "." should never be the first thing in one's $path. It had >something to do with a security hole in Unix. Does anyone know >what and if there is any disadvantage to having "." as the first >entry in $path. It's not a "security hole in UNIX", it's just an unwise policy for most people since it allows them to unwittingly stumble upon Trojan horse traps that malicious persons might have planted. For example, echo 'rm -rf $HOME' > /tmp/ls chmod +x /tmp/ls plants a trap such that anyone who has "." before "/bin" in his $PATH could rue the day that he did the following: cd /tmp ls It is also possible to have problems with this even if no malicious intent is present. To invoke a program located in the current working directory, type ./program_name which works as desired even if "." is not in your $PATH at all.
xtdn@levels.sait.edu.au (02/24/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: > In article <1991Feb22.004010.13359@zip.eecs.umich.edu> bguthy@amazon.eecs.umich.edu (Bala S. Guthy) writes: >>"." should never be the first thing in one's $path. It had >>something to do with a security hole in Unix. > > It's not a "security hole in UNIX", it's just an unwise policy Which begs the question: why do many (most?) Unix's start their default PATH with ":"? This is effectively the same as starting PATH with ".". David Newall, who no longer works Phone: +61 8 344 2008 for SA Institute of Technology E-mail: xtdn@lux.sait.edu.au "Life is uncertain: Eat dessert first"
gwyn@smoke.brl.mil (Doug Gwyn) (02/26/91)
In article <15917.27c718d6@levels.sait.edu.au> xtdn@levels.sait.edu.au writes: >Which begs the question: why do many (most?) Unix's start their default PATH >with ":"? This is effectively the same as starting PATH with ".". UNIX does not know about PATH; that is a function of a shell. Most shells will supply a default PATH if one is not explicitly set. Good shells allow the system administrator to ensure that an appropriate local default is always set for login shells. Good shells also have a reasonable default value for PATH.
bcs@waikato.ac.nz (06/18/91)
In article <44248@netnews.upenn.edu>, chip@pender.ee.upenn.edu (Charles H. Buchholtz) writes: > When I want to lock an account I change the shell to something that > will print out an explanation. This is nicer for the person being > locked out. It also prevents login, rlogin, telnet, , rsh, and ftp > (because the shell is not listed in /etc/shells). > I adopted a slightly different approach when I had a less-than-trustworthy student thrust apon one of our HP-UX systems. We decided it should have access only when the lab was supervised, so I added some logic into /etc/csh.login to check for the existance of a file named after the user currently logging in. If found, issue a cute message and logout, other- wise continue as normal. A csh script run by cron removes the file to allow the peasent to login, and recreates it (and kills said peasent) at the end of it's allowed session - all without intervention. I found pros and cons here: csh.login had to ignore interrupts, and I had to place an ACL restiction on "chsh" (couldn't be bothered doctoring /etc/profile); on the other hand, it does allow me to implement time restrictions on individual users with zilch trouble. The student is in no doubt as to why it can't log in, and logs out promptly as the end-point nears. Brent. -- +-Brent Summers, U of Waikato, NZ----------------------------------------+ | "Laugh and the world ignores you. Crying doesn't help either." | | All opinions expressed are, of course, solely my own errors. | +------------------------------------------------------bcs@waikato.ac.nz-+