* Re: I have a question... [not found] ` <SPIEGEL.94Oct10115716@moskau.bruessel.informatik.uni-stuttgart.de> @ 1994-10-12 17:33 ` David Emery 1994-10-14 1:21 ` Keith Thompson @pulsar ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: David Emery @ 1994-10-12 17:33 UTC (permalink / raw) 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 ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: I have a question... 1994-10-12 17:33 ` I have a question David Emery @ 1994-10-14 1:21 ` Keith Thompson @pulsar 1994-10-14 16:46 ` Andre Spiegel 1994-10-15 11:28 ` I have a question Keith Thompson @pulsar 1994-10-14 7:38 ` Henri Altarac 1994-10-14 21:25 ` Kevin Cline 2 siblings, 2 replies; 12+ messages in thread From: Keith Thompson @pulsar @ 1994-10-14 1:21 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: I have a question... 1994-10-14 1:21 ` Keith Thompson @pulsar @ 1994-10-14 16:46 ` Andre Spiegel 1994-10-14 14:16 ` David Emery 1994-10-15 11:28 ` I have a question Keith Thompson @pulsar 1 sibling, 1 reply; 12+ messages in thread From: Andre Spiegel @ 1994-10-14 16:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: I have a question... 1994-10-14 16:46 ` Andre Spiegel @ 1994-10-14 14:16 ` David Emery 1994-10-14 21:32 ` Norman H. Cohen 0 siblings, 1 reply; 12+ messages in thread From: David Emery @ 1994-10-14 14:16 UTC (permalink / raw) >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 ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: I have a question... 1994-10-14 14:16 ` David Emery @ 1994-10-14 21:32 ` Norman H. Cohen 1994-10-17 10:34 ` Ada programs in a UNIX environment (was Re: I have a question...) Andre Spiegel 0 siblings, 1 reply; 12+ messages in thread From: Norman H. Cohen @ 1994-10-14 21:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Ada programs in a UNIX environment (was Re: I have a question...) 1994-10-14 21:32 ` Norman H. Cohen @ 1994-10-17 10:34 ` Andre Spiegel 0 siblings, 0 replies; 12+ messages in thread From: Andre Spiegel @ 1994-10-17 10:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: I have a question... 1994-10-14 1:21 ` Keith Thompson @pulsar 1994-10-14 16:46 ` Andre Spiegel @ 1994-10-15 11:28 ` Keith Thompson @pulsar 1 sibling, 0 replies; 12+ messages in thread From: Keith Thompson @pulsar @ 1994-10-15 11:28 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: I have a question... 1994-10-12 17:33 ` I have a question David Emery 1994-10-14 1:21 ` Keith Thompson @pulsar @ 1994-10-14 7:38 ` Henri Altarac 1994-10-14 21:25 ` Kevin Cline 2 siblings, 0 replies; 12+ messages in thread From: Henri Altarac @ 1994-10-14 7:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: I have a question... 1994-10-12 17:33 ` I have a question David Emery 1994-10-14 1:21 ` Keith Thompson @pulsar 1994-10-14 7:38 ` Henri Altarac @ 1994-10-14 21:25 ` Kevin Cline 2 siblings, 0 replies; 12+ messages in thread From: Kevin Cline @ 1994-10-14 21:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: I have a question... [not found] <1994Oct07.034523.161470@zeus.aix.calpoly.edu> [not found] ` <SPIEGEL.94Oct10115716@moskau.bruessel.informatik.uni-stuttgart.de> @ 1994-10-13 17:13 ` James A. Krzyzanowski 1994-10-13 15:29 ` David Emery 1 sibling, 1 reply; 12+ messages in thread From: James A. Krzyzanowski @ 1994-10-13 17:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: I have a question... 1994-10-13 17:13 ` James A. Krzyzanowski @ 1994-10-13 15:29 ` David Emery 0 siblings, 0 replies; 12+ messages in thread From: David Emery @ 1994-10-13 15:29 UTC (permalink / raw) 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 ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada programs in a UNIX environment (was Re: I have a question...) @ 1994-10-20 11:01 The Trooper 0 siblings, 0 replies; 12+ messages in thread From: The Trooper @ 1994-10-20 11:01 UTC (permalink / raw) 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 # ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1994-10-20 11:01 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1994Oct07.034523.161470@zeus.aix.calpoly.edu> [not found] ` <SPIEGEL.94Oct10115716@moskau.bruessel.informatik.uni-stuttgart.de> 1994-10-12 17:33 ` I have a question David Emery 1994-10-14 1:21 ` Keith Thompson @pulsar 1994-10-14 16:46 ` Andre Spiegel 1994-10-14 14:16 ` David Emery 1994-10-14 21:32 ` Norman H. Cohen 1994-10-17 10:34 ` Ada programs in a UNIX environment (was Re: I have a question...) Andre Spiegel 1994-10-15 11:28 ` I have a question Keith Thompson @pulsar 1994-10-14 7:38 ` Henri Altarac 1994-10-14 21:25 ` Kevin Cline 1994-10-13 17:13 ` James A. Krzyzanowski 1994-10-13 15:29 ` David Emery 1994-10-20 11:01 Ada programs in a UNIX environment (was Re: I have a question...) The Trooper
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox