Solved Script (pw) to change a user account password

[Keve]

Recently I decided to extend the functionality of my home server, so I could change my FreeBSD password through the web interface I put together. A little research led me to the manual page of pw, and I found exactly what I needed.

pw usermod -n johnsmith -h fd

However, I have trouble recognizing what form the "-h fd" part should take.
Once I have the new password in a variable, what do I do to pass that over to pw through a file-descriptor?
Could someone give me an example or a hint of how this is supposed to be implemented in perl or the bourne shell?

 

[pboehmer]

How about:

echo "newpassword" | pw usermod -n johnsmith -h 0

 

[SirDice]

However, I have trouble recognizing what form the "-h fd" part should take.

The fd refers to a file descriptor. FD 0, 1 and 2 are defined by default with 0 referring to STDIN.

With Perl you can do things like this:

my $user = "johnsmith";
my $passwd = "supersecret";
open( PW, "| pw usermod -n $user -h 0");
print(PW, "$passwd");
close(PW);

 

[Keve]

OK, so this is actually super simple.
I expected some sort of magic jiggery-pokery around this. Instead of overcomplicating with my imagination, I should have just drunk a beer.

SirDice, your example is very useful. Just be aware that old style file-descriptors are discouraged in perl now. So I will use
open( my $pwfd, "| pw usermod -n $user -h 0");
instead.

 

[SirDice]

Just be aware that old style file-descriptors are discouraged in perl now.

Yes, I know. I should have used FileHandle instead but this was just a quick and dirty example to illustrate how you could use it.

 

[steve_o314]

Just be aware that old style file-descriptors are discouraged in perl now.

I'm glad I read this. I didn't know the new method is to use empty variables in Perl FileHandles now. I've been using the old way for over 7 years. Would this be the same for directory handles as well?

 

[Keve]

The old way still works fine, Steve. But it is more prone to errors and vulnerabilities, hence the move towards the use of new-style file handles, which also happen to be more consistent with how other things are done in perl.

And YES, the new style also applies to Directory Handles.

Just remember to avoid using handles without a dollar sign, and always use an uninitialized scalar variable instead.
Gabor Szabo in his Perl Maven series explains the reasons very well.

Don't Open Files in the old way

And just to clarify: I tend to use File Handle and File Descriptor interchangeably. Which is incorrect, because they are not the same. Bad habit, I should pay more attention to.

 

[Keve]

To steer things back towards FreeBSD and my original problem of believing the "-h fd" part being something complex ...
does anybody know a form of use for this OTHER THAN fd being zero?

The reason I am asking (and the reason of my original confusion) is because if it is always zero --meaning stdin-- then what is the point of -h getting its value on the command line. I mean, pw obviously will never read the new password from its own fd=1 (stdout) and fd=2 (stderr). Meanwhile a value of 3 or higher could be a valid File Descriptor in the perl or bash code calling pw, but that particular File Descriptor value would still not exist for pw --because it has its own File Descriptors. So why implement a "-h fd" in pw's code instead of something like "--readFromStdin", which always means fd=0.

 

[olli@]

To steer things back towards FreeBSD and my original problem of believing the "-h fd" part being something complex ...
does anybody know a form of use for this OTHER THAN fd being zero?

You can create new file descriptors, of course. For example, in a shell script you can do that with the exec X<&Y syntax. You can create new file descriptors in Perl and other languages, too, of course, simply by opening files (or FIFOs, or whatever; in theory it could even be a network socket).

Meanwhile a value of 3 or higher could be a valid File Descriptor in the perl or bash code calling pw, but that particular File Descriptor value would still not exist for pw --because it has its own File Descriptors.

If you create the file descriptor before forking the child process that is executing the pw command, then it inherits the file descriptor.

For a very simple example, please look at this shell script snippet that demonstrates how input can be passed to a command using several file descriptors.

I agree that, in the case of the pw command's -h option, stdin a.k.a. FD 0 will be used in most cases, so an option like “--read-from-stdin” would work as well in most cases. However, I think it's a good idea to allow other file descriptors to be specified, because you never know what use-case some creative soul comes up with. If improved flexibility comes at near-zero cost, then why not allow it?

 

[Keve]

Excellent example. Taught me things I did not know before.