The 'read' command accepts a '-s' parameter, which suppresses the echo to screen, and that's what I have done. That means nothing at all echoes to the screen, which I guess is good as noone can guess your password based on its length.
It might be a concern to someone using it the first time though, as they type the password and nothing displays. But, they would quickly realise that it works.
Comments:Posted on 14 Jun 2008, 18:30 by Feverfew
To dumb figure it out quickly? Yes i am.
"they would quickly realise that it works"
I hope there faster then me.
With xlock It took me three years of off and on searching (forums/interweb & such) too figure that one out. I borked a lot of Puppy cd/dvds before I learned first thing first delete the xlock icon.
Posted on 16 Jun 2008, 7:40 by wildpossum
read squashes spaces
I don't know if the busybox read is the one in ash, but if so, then it has in common with the read in bash that it breaks the input into words using $IFS. So a password with two or more spaces would get the spaces turned into a single space. I suppose you would only hit the problem if your password had more than one consecutive space.
Posted on 16 Jun 2008, 9:52 by wildpossum
read also handles backslashes
The other thing read will do is treat \ specially, so the password better not have \ in it.
Posted on 17 Jun 2008, 6:46 by Viking Sailor
Not echoing an "*" when the user inputs his password is way different then what most users are use to. This will require every user to discover and remember something that is unique to puppy. I believe that not having an echo for the password will be very frustrating for the users.
I wish I could help you with this but I am not a CLI guru. I wonder how other distributions handle password input?
Thanks for giving us Puppy,
Posted on 17 Jun 2008, 11:44 by Viking Sailor
One char reads
If the busybox read is like the bash read it should be possible to do a one char read using the -n 1 parameter.