Re: Ada programs in a UNIX environment (was Re: I have a question...)

Re: Ada programs in a UNIX environment (was Re: I have a question...)

[The Trooper]

spiegel@bruessel.informatik.uni-stuttgart.de (Andre Spiegel) writes:
[snip]
> And what if the mechanism you have re-implemented gets changed (for
> example, a new generation of shells comes up), or your program is to
> be ported to, say, a non-UNIX environment, where there are completely
> different conventions and facilities?
>
 How's about either
	system ("echo $HOME/foo");
 or
	system ("csh -c echo ~/bar");
 ?

 I'm sure you can figure out how to call 'system' from Ada ...

> Andre Spiegel
-- 
#  Bill Crawford, BSc (Hons) Comp Sci Year 4 : w.j.m.crawford@bton.ac.uk  #
# Any views wot I express is not necessarily those of Brighton University #

Re: I have a question...

[David Emery]

The easiest way to 'solve' this problem is to expand the "~" into the
home directory.  The environment variable "HOME" contains the pathname
of the home directory.  Thus it's pretty trivial to implement an
operation that replaces (all) occurances of "~" in a pathname with the
string value of HOME.  

To be more accurate/precise, the best thing to do is to obtain the
pathname to the home directory from the /etc/passwd file, since the
value of HOME could have been changed by the user.

				dave

--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: I have a question...

[Keith Thompson @pulsar]

In <EMERY.94Oct12173346@goldfinger.mitre.org> emery@goldfinger.mitre.org (David Emery) writes:
> The easiest way to 'solve' this problem is to expand the "~" into the
> home directory.  The environment variable "HOME" contains the pathname
> of the home directory.  Thus it's pretty trivial to implement an
> operation that replaces (all) occurances of "~" in a pathname with the
> string value of HOME.  
> 
> To be more accurate/precise, the best thing to do is to obtain the
> pathname to the home directory from the /etc/passwd file, since the
> value of HOME could have been changed by the user.

Alas, it's not quite that easy.

The expansion of '~' is done by the C-shell (csh).  The Bourne shell
(sh) doesn't do this; "echo ~" echoes a single '~' character.  Some sh
variants (e.g., the Korn shell, ksh) mimic csh's tilde expansion.

The C-shell expands '~' to the value of the $HOME environment variable.
This is initially the user's home directory, but it can be changed (and
there are legitimate reasons for doing so).  If you're going to do '~'
expansion, don't second-guess the user by looking for the "real" home
directory in the password file, just grab the value of $HOME.  (Actually,
it's the shell variable $home, but csh ties their values together.)

This applies only to '~' at the beginning of a word, immediately followed
either by the end of a word or a non-alphanumeric character.  If '~'
(at the beginning of a word) is followed by a sequence of alphanumeric
characters, they're taken as a user name, and the sequence is replaced
by the name of that user's home directory (regardless of any environment
variables).  For example, "~buford" might expand to "/home/buford";
"~root" typically expands to "/".  Note that "~nosuchuser" is an error;
you'll have to decide how to deal with this.  If '~' appears other than
at the beginning of a word, leave it alone; "a~b" should expand to "a~b".
This is important, since many programs append a '~' character to the
names of backup files.

Also, an experiment I just did shows that the shell doesn't necessarily
look for just alphanumeric characters; "echo ~kst.foo" reported "Unknown
user: kst.foo." under tcsh (a csh variant), but echoed "~kst.foo"
under csh.  The man page is less than clear on this subject.

So, how do you determine a user's home directory, given the user's name?
Reading the file "/etc/passwd" won't necessarily work; many systems don't
store all the password information there (YP/NIS).  In C, you can call
getpwnam() (or getpwnam_r() if you're worried about reentrancy and the
system supports it) and extract the directory name from the result's
pw_dir field.  If your vendor supports the POSIX/Ada interface, the
equivalent (assuming User_Name is a string containing the user name) is

    POSIX_User_Database.Initial_Directory_Of
	( POSIX_User_Database.Get_Database_Item
	     ( POSIX.To_POSIX_String
		  ( User_Name ) ) );

Note that the vast majority of Unix programs do *not* support '~'
expansion (or environment variable expansion, or wildcard expansion).
This job is normally left to the shell.  I strongly recommend that you
do the same.

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)

Re: I have a question...

[Andre Spiegel]

Keith Thompson writes:
> Note that the vast majority of Unix programs do *not* support '~'
> expansion (or environment variable expansion, or wildcard expansion).
> This job is normally left to the shell.  I strongly recommend that you
> do the same.

I strongly agree on that. In my opinion, Ada programs intended to run
on UNIX machines should behave as UNIX-like as possible, which means,
for example, to use the command line, and the standard input and output
streams as the main, if not the only means of communication.

I should say that if a UNIX program needs to ask the user for a file
name, something must be wrong with its design.

--
Andre Spiegel                     |  This life is a test. It is only a test.
                                  |  Had this been an actual life, you would
University of Stuttgart, Germany  |  have received further instructions as to
Computer Science                  |  where to go and what to do.
                                                            -- Author unknown

	   email: spiegel@bruessel.informatik.uni-stuttgart.de

Re: I have a question...

[David Emery]

>I should say that if a UNIX program needs to ask the user for a file
>name, something must be wrong with its design.

Some Unix programs are filters.  They read standard input, and write
to standard output.  This is a SMALL SUBSET of Unix programs.
Compilers, for instance, may well ask for a filename if the user
provides no filename on the command line.  Thus this assertion (that a
Unix program that has to ask for a filename is 'bad') is not valid.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: I have a question...

[Norman H. Cohen]

In article <EMERY.94Oct14141610@goldfinger.mitre.org>,
emery@goldfinger.mitre.org (David Emery) writes: 

|> >I should say that if a UNIX program needs to ask the user for a file
|> >name, something must be wrong with its design.
|>
|> Some Unix programs are filters.  They read standard input, and write
|> to standard output.  This is a SMALL SUBSET of Unix programs.
|> Compilers, for instance, may well ask for a filename if the user
|> provides no filename on the command line.  Thus this assertion (that a
|> Unix program that has to ask for a filename is 'bad') is not valid.

Indeed.  For example, a text editor may support commands to insert a
given file in the current editing buffer, write all or part of the
current editing buffer to a file, or open a new buffer and read some file
into it.  It is a real pain if the user can't use symbols like ~ in such
commands, so the editor ought to expand the file names in such commands.

--
Norman H. Cohen    ncohen@watson.ibm.com

Ada programs in a UNIX environment (was Re: I have a question...)

[Andre Spiegel]

I wrote:
> I should say that if a UNIX program needs to ask the user for a file
> name, something must be wrong with its design.

On which Dave Emery replied:
> Some Unix programs are filters.  They read standard input, and write
> to standard output.  This is a SMALL SUBSET of Unix programs.
> Compilers, for instance, may well ask for a filename if the user
> provides no filename on the command line.  Thus this assertion (that a
> Unix program that has to ask for a filename is 'bad') is not valid.

And Norman Cohen said:
> Indeed.  For example, a text editor may support commands to insert a
> given file in the current editing buffer, write all or part of the
> current editing buffer to a file, or open a new buffer and read some file
> into it.  It is a real pain if the user can't use symbols like ~ in such
> commands, so the editor ought to expand the file names in such commands.

Of course, my above statement was intended as a rule of thumb, nothing
more. Sort of a general orientation for Ada programming under UNIX: to
fit neatly into what is already there. Naturally, there are cases when
interactive programs *do* have to ask for filenames, and the like. I
am just saying that sometimes this can be avoided, and, if so, should
be avoided. For example, I wouldn't want a compiler to ask
interactively, even if I didn't provide a filename. Think of the
confusion if you try to use that compiler in a shell script, and you
forget to supply the filename (or the file doesn't exist).

If something like file name expansion is really needed in your own
program (a text editor would be an example, I agree), the "rule of
thumb" should also be applied, by trying to use the already existing
mechanism, not (without good reason) something you write yourself JUST
IN ORDER TO SIMULATE A FACILITY YOU CAN'T FIND ACCESS TO. Chances are
that you'll write something _almost_, but not entirely identical. And
what if the mechanism you have re-implemented gets changed (for
example, a new generation of shells comes up), or your program is to
be ported to, say, a non-UNIX environment, where there are completely
different conventions and facilities? 

Finally, I think that when you really try to find a UNIX-like
solution, you often end up with something you would not have thought
about otherwise, but which proves quite handy in such an
environment. Sometimes it's just a choice between two ways of doing
things, none of which being any more difficult to implement than the
other.

--
Andre Spiegel                     |  This life is a test. It is only a test.
                                  |  Had this been an actual life, you would
University of Stuttgart, Germany  |  have received further instructions as to
Computer Science                  |  where to go and what to do.
                                                            -- Author unknown

	   email: spiegel@bruessel.informatik.uni-stuttgart.de