Re: Ways and means - tool existence question.
Daniel Pittman [EMAIL PROTECTED] writes: While working on the VC remote username code, I believe I have a solution. To know how general it is, however, I would like to know if there are any platforms out there that don't have the grep(1) and cut(1) tools installed. I'm not sure that the name-to-number mapping is the right thing to do, but I have received no response from the Emacs team. In Emacs 20.3, there was only one place where the (numeric) user id which is returned from file-attributes was ever used. And that was in vc.el, and only to return the user _name_ associated with the _id_! I think it would be a great benefit if we could just make file-attributes return the user _name_ and use it as-is. But I'm sure it would be difficult to do in a backward-compatible way. Do you think I should try to talk to the Emacs maintainers again? If there is any platform that does not have a user readable /etc/password file containing uid and username mappings, it would also be useful to know. There are NIS and NIS+, and then there's NetInfo. (Does anybody actually use that?) I think the way to go is this: say "nistest passwd.org_dir" and check the exit status to see if NIS+ is installed. If it is, take note of that and use "niscat passwd.org_dir" to get the passwd file. If NIS+ isn't installed, check for NIS by calling ypwhich. If NIS is installed, use "ypcat passwd" for the passwd file. I think you want to look in /etc/passwd, too, even if NIS+ or NIS are installed. kai -- Life is hard and then you die.
Re: Ways and means - tool existence question.
On 10 Oct 1999, Kai Großjohann [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: In my VC, the only place that actually calls (vc-user-login-name) with a uid is: (defun vc-file-owner (file) ;; Return who owns FILE (user name, as a string). So, rather than spend a lot of effort putting in a hack that will not work so well (I think) for the mapping, I will am writing an advice for this function to make it behave sensibly and not try to map uid = name for rcp files. Let 'ls' do all the hard work for us. :) I think this function already uses the uid if it can't find a name. Dang. I shouldn't write mail so early on a Sunday. I expressed myself badly. What I intended to say was that I can (er, have) written a function that makes vc-file-owner parse the output of 'ls -Ldl' to get the login name of the user that owns the file. With this in place there are no calls in VC (or anywhere else for that matter) to 'user-login-name' with a parameter. The only question left is what should 'vc-user-login-name' (with no parameter) return when the current file is accessed by rcp? I think that this should be the login name from the rcp path - that is the same value as a 'co' will set on the working file. I have not yet implemented that path and so will not attach a patch yet. It is still a little while of work to make that finished and I should like to test it somewhat tomorrow. Daniel -- The future is always a fairy land to the young. -- George Augustus Sala
Re: Ways and means - tool existence question.
Daniel Pittman [EMAIL PROTECTED] writes: In my VC, the only place that actually calls (vc-user-login-name) with a uid is: (defun vc-file-owner (file) ;; Return who owns FILE (user name, as a string). So, rather than spend a lot of effort putting in a hack that will not work so well (I think) for the mapping, I will am writing an advice for this function to make it behave sensibly and not try to map uid = name for rcp files. Let 'ls' do all the hard work for us. :) I think this function already uses the uid if it can't find a name. kai -- Life is hard and then you die.
