Re: I have a question...

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...

[David Emery]

Let me clarify what is going on here, since there appears to be some
confusion.  

The Unix (POSIX) system interface does NOT recognize the "~~
character.  This (like other wildcards, such as "*" and "?") is
processed by the shell (or by a 'friendly' applications program.)

So a call to OPEN (FILENAME => "~/myfile") will not work correctly if
the OPEN procedure does not interpret the "~" character.  This would
be the case for POSIX_IO.OPEN, for instance.

A call to SYSTEM (COMMAND => "~/bin/myprogram ~/myfile") will probably
work correctly, assuming that SYSTEM here is the Unix system command,
which invokes the shell.

What is interesting is a call to TEXT_IO.OPEN (NAME => "~/myfile").
This is interesting because there is no requirement for TEXT_IO to
process wildcards, but it is not 'illegal' for TEXT_IO to do so.  Nor
does the POSIX/Ada standard (IEEE Std 1003.5-1992) say anything about
this (maybe it should...)  As a result, this call to TEXT_IO.OPEN is
clearly implementation-defined, and different Ada compilers on the
same operating system may give different results.

I hope this clarifies the situation.  The bottom line:  "~" is a
wildcard processed by the shell, just as "*" and "?".  Some friendly
applications duplicate the shell processing, but users should not
expect this for 'standard' interfaces such as TEXT_IO and POSIX_IO.

				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...

[James A. Krzyzanowski]

Jana Wonder Twin #1 (kamundse@harp.aix.calpoly.edu) wrote:
: I am working on a program and it asks the user to type in the name of
: the file from which it should take data.

: I would like the user to be able to specify (this is in UNIX) a file
: that does not have to be within the directory from which they are
: executing the program.

: But I cannot figure out how I might (or even if I can) do this.  I think
: if the user types in ~survey/data or /survey/data that it will not
: recognixe a ~ or / as a UNIX command but as characters in the file name.

It may depend upon which Ada compiler you are using.  We have HP 9000
workstations and are running HP/Alsys Ada.  I have a program already that asks
the user to enter a filename and then do some processing on it.  I tried using
"~" and "/" in the filename and it worked like a champ.

If you don't have Alsys Ada, then the compiler may also provide the capability
to execute UNIX commands within your Ada code.  If this is the case, you could
use UNIX to "cat" the file or whatever.
-- 
---------------------------------------------------------------------------
James A. Krzyzanowski - Senior Software Engineer - AFATDS
Magnavox Electronic Systems Company * Fort Wayne, IN 46808 * (219) 429-6446
E-Mail : jak@pseserv2.magec.com

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...

[Henri Altarac]

David Emery (emery@goldfinger.mitre.org) wrote:
: 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.  

Don't forget that ~user can also be used and expands into user's
home directory. 

: 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.

The passwd file cannot be used if your system is running the Yellow pages.

On SUN, there is a service 'getpwnam' that does the ~user translation. 


Henri Altarac
-----
haltarac@rain.org	(805)683-3045

Re: I have a question...

[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...

[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...

[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...

[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...

[Kevin Cline]

In article <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.

It is not a good idea to read /etc/passwd.  Use getpwent(2).  It knows
about NIS.

Actually, various UNIX shell flavors differ in their interpretation of ~.
The c-shell always replaces ~ with the value of the home variable,
or if that is not set (the usual case) then with the user's login directory.
The Bourne shell does not support ~ at all.
The Korn shell replaces ~ with the value of the HOME variable.
GNU bash replace ~ with the value of the HOME environment variable.

You should probably use the HOME environment variable, since users that
change it are probably pretending to be someone else for a good reason.

Kevin Cline

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

Re: I have a question...

[Keith Thompson @pulsar]

In <some article> Norman H. Cohen (ncohen@WATSON.IBM.COM)
> 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.

Agreed.  The usual way to do this, I think, is for the program to
scan the user's input for special characters ('~', '*', etc.), and,
if it finds any, invoke a shell and feed the string to it.  The shell
to invoke is determined by the value of the environment variable $SHELL.

I've confirmed that vi under SunOS 5.3 (Solaris 2.3) and SunOS 4.1.3
(Solaris 1.whatever) actually does this.  I have my $SHELL set to point
to tcsh (an enhanced version of csh).  When I type

    :r ~/tmp

it invokes tcsh to expand it.  If I set $SHELL to /bin/sh, the same
command yields an error message:
    
    "~/tmp" No such file or directory

since /bin/sh doesn't do ~ expansion.

This seeming inconsistency is a good thing, IMHO; each user gets the same
kind of special character handling from vi as from his or her preferred
command shell.  Invoking a shell may seem expensive, but blinding speed
doesn't matter much when you're processing text from the user's keyboard.

It would be nice to have a predefined library function that does this
kind of expansion without actually invoking a shell; it could look at
$SHELL to determine what kind of expansion to do and/or take an optional
extra argument to tell it to mimic a specified shell.  Unfortunately,
this isn't predefined in Unix.  Given the POSIX/Ada interface, there's
no reason it couldn't be written in Ada.

To summarize:

If you can get all file names from the command line (where they will
already have been expanded by the shell with no effort on your part),
do so.  For example, if I forget to provide a file name on the command
line, I don't mind begin given a usage message and told to try again;
I don't need the program to prompt me for it.  Your mileage may vary.

If you need to provide expansion, invoke the user's shell to do it.
This is appropriate for interactive commands like text editors.
Don't bother doing your own ~ and environment variable expansion;
your probability of being totally consistent with the shell is small.

-- 
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...

[ncohen]

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