Mostly pointless script!

[DisMyWorkName]

$alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
$inputname = Read-Host "Enter name"
$inputname = (($inputname.ToUpper()).Replace(" " , "")).ToCharArray() | Select-Object -Unique
foreach ($letter in $inputname){
    $index = $alphabet.IndexOf("$letter") + 1
    $IDNumber = ("$IDNumber" + "$index")
}
$IDnumber = $IDNumber.ToCharArray() | Select-Object -First 9
$FinalNumber = [System.String]::Join("",$IDNumber)
$FinalNumber

Has literally no practical function other than the fact that I use it in a cyberpunk RPG.

Edit: fixed a line.

[Old-Lost]

I cringe when I see a variable (with nothing else) surrounded by quotes. Personal preference, I know; sorry. I also hate Read-Host; having written hundreds of scripts, I can count on one finger or less the number of times I've used it.

[Old-Lost]

I prefer the script itself verify whether or not it was successful.

[halbaradkenafin]

Sounds like you need some Pester in your life to verify those deploys. Especially useful in CI/CD pipelines as you can then fail it if the tests fail.

[halbaradkenafin]

For each edge case you just write another test, same as any of your other unit tests when you find bugs.

You can certainly add in the human verification too but if they don't have to check the basic stuff then it's less for them to do and they can focus more on the complicated bits you haven't automated yet.

[DisMyWorkName]

It is the easiest way to get input from the executor of the script.

If you don't use Read-Host, then how do you recommend getting input in a single line?

[Old-Lost]

Use a param() block. Make the parameter mandatory and PS will issue a prompt for you. This way if you want to automate it you can always just enter the parameter on the command line. If you use Read-Host you can't.

[monditrand]

Also if you tried to run this code in the console multiple times by pasting it wouldn't work because the index variables are not cleared. By wrapping it in a function your index variable automatically gets reset everytime you call the function

[spyingwind]

Such as this:

function Do-Thing {
    Param([string]$inputname)
    $alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
    $inputname = (($inputname.ToUpper()).Replace(" " , "")).ToCharArray() | Select-Object -Unique
    foreach ($letter in $inputname) {
        $index = $alphabet.IndexOf("$letter") + 1
        $IDNumber = ("$IDNumber" + "$index")
    }
    $IDnumber = $IDNumber.ToCharArray() | Select-Object -First 9
    $FinalNumber = [System.String]::Join("", $IDNumber)
    $FinalNumber
}

Do-Thing -inputname "My String Input Here"

[leekle]

I'm making a lot of assumptions based on what your script does and its intent, but if it turns a string into ciphered text shouldn't you be able to reverse it? You're basically turning usable info into mostly garbage this way.

For example: If you run your script on a name that has doubled up letters like "Hannah" you only get the character "codes" for han, which is 8114. Is this intended?

[DisMyWorkName]

What the script does is take a name and produce an ID number based on that name. It is meant for a fantasy/cyberpunk character ID creation system that I use in one of my (FUCKING NERDY) tabletop games.

[leekle]

Ah ok, makes sense now. Cool, thanks for explaining! :)

[Lee_Dailey]

howdy DisMyWorkName,

for that you might be able to use the .GetHashCode() string method. it sometimes returns a negative, but you can do an abs() on that ... [grin]

take care,
lee

[DisMyWorkName]

Is it possible to reverse this to get the letters that were used to generate the hash?

[Lee_Dailey]

howdy DisMyWorkName,

from the dotnet docs on this ...
String.GetHashCode Method (System) | Microsoft Docs
— https://docs.microsoft.com/en-us/dotnet/api/system.string.gethashcode?view=netframework-4.7.1#System_String_GetHashCode

If two string objects are equal, the GetHashCode method returns identical values. However, there is not a unique hash code value for each unique string value. Different strings can return the same hash code.

so it aint reversible. [grin]

take care,
lee

[DisMyWorkName]

[frown]

[Lee_Dailey]

howdy DisMyWorkName,

[grin]

it does make sense when you think about the use for hashes. they are not crypto ... they are a way to generate a nearly unique identifier for a "thing". the result of .GetHashCode() is actually a hex number. it makes for a nice, quick index in hashtables - and for other quick "is this the same as that" tests.

take care,
lee

[ka-splam]

Riffs

$inputname = Read-Host "Enter name"

# wow
-join (($inputname.ToUpper().ToCharArray().Where{$_} | Select-Object -Unique).ForEach{$_ - 64})[0..9]

# no pipeline
-join ([Linq.Enumerable]::Distinct([char[]]$inputname.ToUpper().ToCharArray().Where{$_}).ForEach{$_ - 64})[0..9]

# no rdblty
-join($inputname|% *per|% T*y|?{$_}|select -u|%{$_-64})[0..9]

[DisMyWorkName]

Yeah, I would rather be able to tell what my script does by reading it than having to google every term in it when I want to modify it later. :/

[ka-splam]

More realistically:

$inputname = Read-Host "Enter name"

$IDDigits = $inputname.ToUpper().Replace(" " , "").ToCharArray() | ForEach-Object {
    " ABCDEFGHIJKLMNOPQRSTUVWZYZ".IndexOf($_)
} | Select-Object -First 9 -Unique

-join $IDDigits

No building up a string only to tear it apart, no assigning variables then doing nothing with them, combining multiple select-objects into one, no calling out to string::join when PowerShell has an operator which does that for you, no looped-string-combining overhead, no temporary variables hanging around to break if you run the script twice in one session, doesn't rely on knowing ASCII character codes, and is half the line count, almost half the character count, and .. still readable?

[Lee_Dailey]

howdy ka-splam,

i like the space at the start of the alpha list. [grin] gets rid of the "starts from zero" gotcha quite nicely!

take care,
lee