Ecsuse the noise folks. To clear up any confusion...

In a hurry the last few days & I named a function I wrote after an
exsisting hash named dbj2. Bad idea on my part, so please allow me
to own my mistake & take full responsibilty. The code has been
renamed to "mHash" (using Camel case) meaning "Mike's Hash".

mHash info here:

https://porkchop.neocities.org/notes/mHash.txt

--
:wq
Mike Sanders

porkchop@invalid.foo (Mike Sanders) writes:
> Ecsuse the noise folks. To clear up any confusion...
>
> In a hurry the last few days & I named a function I wrote after an
> exsisting hash named dbj2. Bad idea on my part, so please allow me
> to own my mistake & take full responsibilty. The code has been
> renamed to "mHash" (using Camel case) meaning "Mike's Hash".
>
> mHash info here:
>
> https://porkchop.neocities.org/notes/mHash.txt

Glad you changed your mind.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Glad you changed your mind.

Well, certainly would've been ignoble to've done otherwise.

Actually a good thing in some respects as I can concentrate
on the key idea (there's two differing ideas running through
the code right now).

--
:wq
Mike Sanders

Hey folks, quick update as promised elsewhere (plus easier this way):

Yes the website was taken down. Long story short, a bad presence
here that I simply cant work with anymore, too much drama.

Here's something, in over 3 hours time, 52 of you did visit & 13
downloaded the mHash() draft, which I thought was nifty, appreciate it.

Nah dbj2 is not an issue, I was moving so quickly I simply did not consider
choosing another name for the function. A knuckle-headed oversite when you
consider I did the same thing a few days prior when I wrote a function named
ord(). Trust me, a very humbling snafu to have done so publicly twice in a
week's time.

I use ZOC: https://www.emtec.com/zoc/index.html

No not going anywhere, but life often seeks its own level, its all good. =)

Yep, mHash will be available again, but this time only via email. Any how,
let's check it out (sorry if its too terse)...

First the new function signature: mHash(str, key, hash, x, y, ascii)

Example usage: hash = mHash(my_input, my_key)

Example csv file (we'll choose sally, her hash is
the number directly below in the same column):

# jenny, sally, wendy

4044119583, 156734252, 0782926302
apple, she, pear
these, knows, another
fubar, how, blurb

Example commandline invocation:

awk -vNAME=sally -vKEY=2147483647 -f script.awk data.csv

Example script, we'll constrain processing *exclusively* to sally's column

BEGIN {

FS = "," # set field separator to comma
UNLOCK = 0 # when > 0, column is 'unlocked'
HASH = mHash(NAME, KEY) # initialize hash & lets go...

}

NR == 3 { # start @ 3rd line
for (x = 1; x <= NF; x++) {
if ($x ~ HASH) {
UNLOCK = x;
break;
}
}
}

NR > 3 && UNLOCK {print $UNLOCK} # if unlocked, print only sally's column

# eof

Hey, thanks again!

--
:wq
Mike Sanders

Mike Sanders <porkchop@invalid.foo> wrote:

> Nah dbj2...

Typo, I mean djb2

--
:wq
Mike Sanders

In article <uf30ij$3hmge$1@dont-email.me>,
Mike Sanders <porkchop@invalid.foo> wrote:
....
>I use ZOC: https://www.emtec.com/zoc/index.html

Wow! Haven't heard anything about ZOC in decades. Does it still exist?
In what form? What has it evolved into?
(Just out of curiosity, why *did* you mention it here?)

Note: I used ZOC way back when in OS/2 days - for serial comms only.
Nobody uses serial anymore (and if they did, all you need is screen(1)), so
is there any point in ZOC anymore?

Note; I really liked it - back in OS/2 days, so don't take any of this as
slagging it or as negativity.

--
(Cruz certainly has an odd face) ... it looks like someone sewed pieces of a
waterlogged Reagan mask together at gunpoint ...

http://www.rollingstone.com/politics/news/how-america-made-donald-trump-unstoppable-20160224

Kenny McCormack <gazelle@shell.xmission.com> wrote:

> Wow! Haven't heard anything about ZOC in decades. Does it still exist?
> In what form? What has it evolved into?
> (Just out of curiosity, why *did* you mention it here?)

Dude you should see it these days! Even custom scripting using REXX
(popular on IBM mainframes, really great under Windows whitch seems
to lack anything worth using scriptwise natively):

https://en.wikipedia.org/wiki/Rexx

Well, this whole *debacle* (I always wanted my own debacle!) caused
a spat of emails on my end & since I was anwsering them here, I
included a question from a gentleman (who should consider posting
- sorry if you're reading), but is maybe a little reluctant to do
so, or then again, maybe he's right on the money. Anyhow, he wants
ZMODEM xfer protocol.

> Note: I used ZOC way back when in OS/2 days - for serial comms only.
> Nobody uses serial anymore (and if they did, all you need is screen(1)),
> so is there any point in ZOC anymore?

I use it as it has a tabbed interface, & more options than I could ever
use.

Funny you should mention serial coms... my 1st NIX was Minix. Went out &
built a barebones serial cable myself, took me 4 attempts to get it right.
Then I was logging into my Minix boxen from DOS using Kermit, & daydreaming
of being an 'admin'. Man such a great time...

> Note; I really liked it - back in OS/2 days, so don't take any of this as
> slagging it or as negativity.

OS/2! Just a little before my time. Always thought it looked pretty powerful
compared to Windows.

Nah its all good Kenny. Nice to hear from you again. I see you're still out
in the world & kicking. I've learned *alot* from your posts over the years...

--
:wq
Mike Sanders

porkchop@invalid.foo (Mike Sanders) writes:

> Example csv file (we'll choose sally, her hash is
> the number directly below in the same column):
>
> # jenny, sally, wendy
>
> 4044119583, 156734252, 0782926302
> apple, she, pear
> these, knows, another
> fubar, how, blurb
>
>
> Example commandline invocation:
>
> awk -vNAME=sally -vKEY=2147483647 -f script.awk data.csv
>
>
> Example script, we'll constrain processing *exclusively* to sally's column
>
> BEGIN {
>
> FS = "," # set field separator to comma
> UNLOCK = 0 # when > 0, column is 'unlocked'
> HASH = mHash(NAME, KEY) # initialize hash & lets go...
>
> }
>
> NR == 3 { # start @ 3rd line
> for (x = 1; x <= NF; x++) {
> if ($x ~ HASH) {
> UNLOCK = x;
> break;
> }
> }
> }
>
> NR > 3 && UNLOCK {print $UNLOCK} # if unlocked, print only sally's column

As presented, this is just a complex way of selecting a column so there
must be some context you are considering that provides the actual
security because, as it stands, anyone who can run that awk command can
run a much simpler one to look at any data they like. How do you think
this would be used?

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> As presented, this is just a complex way of selecting a column so there
> must be some context you are considering that provides the actual
> security because, as it stands, anyone who can run that awk command can
> run a much simpler one to look at any data they like. How do you think
> this would be used?

Oh yeah, simply plugin: '156734252'

Have alot of ideas, some already solved, but not yet to my satisfaction.
Time will tell.

--
:wq
Mike Sanders

Mike Sanders <porkchop@invalid.foo> wrote:

> Oh yeah, simply plugin: '156734252'

Forgot to add: print $2

--
:wq
Mike Sanders

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

[...]

One thing I do wonder about is wheather or not
this is valid under Windows:

if (y < 1) print "error" > "/dev/stderr"

In Windows, its simply 'nul' in the current directory.

On my end, in Windows, printing to "/dev/stderr" works
just fine with either mawk or busybox's awk. Still, I'm
skeptical if that's good form under Windows...

--
:wq
Mike Sanders

Mike Sanders <porkchop@invalid.foo> wrote:

> One thing I do wonder about is wheather or not
> this is valid under Windows:
>
> if (y < 1) print "error" > "/dev/stderr"
>
> In Windows, its simply 'nul' in the current directory.

No not 'nul' (got ahead of myself), rather:

stdin: 0
stdout: 1
stderr: 2

Still using /dev under Windows seems odd.

--
:wq
Mike Sanders

Mike Sanders <porkchop@invalid.foo> wrote:

> Mike Sanders <porkchop@invalid.foo> wrote:
>
>> One thing I do wonder about is wheather or not
>> this is valid under Windows:
>>
>> if (y < 1) print "error" > "/dev/stderr"
>>
>> In Windows, its simply 'nul' in the current directory.
>
> No not 'nul' (got ahead of myself), rather:
>
> stdin: 0
> stdout: 1
> stderr: 2
>
> Still using /dev under Windows seems odd.

This works, but feels like a hack if ever there was:

print "this is win stderr" | "cmd /c more 1>&2"

invoke a shell, pipe to more...

--
:wq
Mike Sanders

On 29.09.2023 00:40, Mike Sanders wrote:
> Mike Sanders <porkchop@invalid.foo> wrote:
>
>> Mike Sanders <porkchop@invalid.foo> wrote:
>>
>>> One thing I do wonder about is wheather or not
>>> this is valid under Windows:
>>>
>>> if (y < 1) print "error" > "/dev/stderr"
>>>
>>> In Windows, its simply 'nul' in the current directory.
>>
>> No not 'nul' (got ahead of myself), rather:
>>
>> stdin: 0
>> stdout: 1
>> stderr: 2
>>
>> Still using /dev under Windows seems odd.
>
> This works, but feels like a hack if ever there was:
>
> print "this is win stderr" | "cmd /c more 1>&2"
>
> invoke a shell, pipe to more...
>

(This is probably a question for a Windows/DOS newsgroup
and likely off-topic here. Anyway. Let's make guesses...)

Does DOS support a 'cat' command? - If so then you can maybe
use one of the redirection patterns that are also suggested
for Unix...

print "error" | "cat 1>&2"

(Or maybe the DOS'es 'type' command may replace 'cat' here?)

For Unix (to be tried out for DOS) there's also

print "error" > "/dev/tty"

to get the message directly to the terminal in case that is
the basic requirement, as opposed to redirecting it to FD:2
(which may or may not be the terminal depending on settings
in the surrounding environment).

Janis

On 29.09.2023 02:19, Janis Papanagnou wrote:
> On 29.09.2023 00:40, Mike Sanders wrote:
>> Mike Sanders <porkchop@invalid.foo> wrote:
>>
>>> Mike Sanders <porkchop@invalid.foo> wrote:
>>>
>>>> One thing I do wonder about is wheather or not
>>>> this is valid under Windows:
>>>>
>>>> if (y < 1) print "error" > "/dev/stderr"
>>>>
>>>> In Windows, its simply 'nul' in the current directory.
>>>
>>> No not 'nul' (got ahead of myself), rather:
>>>
>>> stdin: 0
>>> stdout: 1
>>> stderr: 2
>>>
>>> Still using /dev under Windows seems odd.
>>
>> This works, but feels like a hack if ever there was:
>>
>> print "this is win stderr" | "cmd /c more 1>&2"
>>
>> invoke a shell, pipe to more...
>>
>
> (This is probably a question for a Windows/DOS newsgroup
> and likely off-topic here. Anyway. Let's make guesses...)
>
>
> Does DOS support a 'cat' command? - If so then you can maybe
> use one of the redirection patterns that are also suggested
> for Unix...
>
> print "error" | "cat 1>&2"
>
> (Or maybe the DOS'es 'type' command may replace 'cat' here?)
>
>
> For Unix (to be tried out for DOS) there's also
>
> print "error" > "/dev/tty"
>
> to get the message directly to the terminal in case that is
> the basic requirement, as opposed to redirecting it to FD:2
> (which may or may not be the terminal depending on settings
> in the surrounding environment).

And two or three more suggestions... (partly more drastic)

use system() with the DOS specific commands composed as string
concatenated argument.

If you have control over the system you are working on; install
a Cygwin environment and run it in that Unix emulation.

Use a partition on your Windows disk for a Linux emulation.
Or use a live version of Linux from an USB-stick to run that.

> Janis
>

In article <uf37hs$3ins4$1@dont-email.me>,
Mike Sanders <porkchop@invalid.foo> wrote:
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
>> Wow! Haven't heard anything about ZOC in decades. Does it still exist?
>> In what form? What has it evolved into?
>> (Just out of curiosity, why *did* you mention it here?)
>
>Dude you should see it these days! Even custom scripting using REXX
>(popular on IBM mainframes, really great under Windows whitch seems
>to lack anything worth using scriptwise natively):

I've never been at all impressed with/by REXX. Back when OS/2 was a thing,
they were always raving about it (and how great it is), but it always
looked ugly to me.

You could say that REXX is (was) JCL done right, but it is still JCL.
I.e., if you come from an IBM mainframe background (as a lot of OS/2'ers
did), and are used to less-than-great things like JCL, then REXX looks
great. But if you're coming from a Unix background, where good (and
sometimes wonderful) scripting languages are common, then REXX looks like,
well, not-so-great.

>Well, this whole *debacle* (I always wanted my own debacle!) caused
>a spat of emails on my end & since I was anwsering them here, I
>included a question from a gentleman (who should consider posting
>- sorry if you're reading), but is maybe a little reluctant to do
>so, or then again, maybe he's right on the money. Anyhow, he wants
>ZMODEM xfer protocol.

I don't understand this paragraph, but no matter.

>> Note: I used ZOC way back when in OS/2 days - for serial comms only.
>> Nobody uses serial anymore (and if they did, all you need is screen(1)),
>> so is there any point in ZOC anymore?
>
>I use it as it has a tabbed interface, & more options than I could ever
>use.

Do you run it under MS Windows, then?

Anyway, I may check ZOC out again - just for old times sake. I don't do
much with Windows anymore, though. Pretty much all Linux (and thus X
windows).

>Nah its all good Kenny. Nice to hear from you again. I see you're still out
>in the world & kicking. I've learned *alot* from your posts over the years...

I'm here all week.

--
Faith doesn't give you the answers; it just stops you from asking the questions.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

>> (This is probably a question for a Windows/DOS newsgroup
>> and likely off-topic here. Anyway. Let's make guesses...)
>>
>>
>> Does DOS support a 'cat' command? - If so then you can maybe
>> use one of the redirection patterns that are also suggested
>> for Unix...
>>
>> print "error" | "cat 1>&2"
>>
>> (Or maybe the DOS'es 'type' command may replace 'cat' here?)
>>
>>
>> For Unix (to be tried out for DOS) there's also
>>
>> print "error" > "/dev/tty"
>>
>> to get the message directly to the terminal in case that is
>> the basic requirement, as opposed to redirecting it to FD:2
>> (which may or may not be the terminal depending on settings
>> in the surrounding environment).
>
> And two or three more suggestions... (partly more drastic)
>
> use system() with the DOS specific commands composed as string
> concatenated argument.
>
> If you have control over the system you are working on; install
> a Cygwin environment and run it in that Unix emulation.
>
> Use a partition on your Windows disk for a Linux emulation.
> Or use a live version of Linux from an USB-stick to run that.

Janis these are really good options. I don't know what I'll wind
up with, but you've scored another hit in my notes. I like
system() as its intrinsic to most every awk.

Anyhow, as always appreciate it.

--
:wq
Mike Sanders

Kenny McCormack <gazelle@shell.xmission.com> wrote:

> I've never been at all impressed with/by REXX. Back when OS/2 was a thing,
> they were always raving about it (and how great it is), but it always
> looked ugly to me.

Oh yeah. As far as theses things go, it beats powershell IMO.
> You could say that REXX is (was) JCL done right, but it is still JCL.
> I.e., if you come from an IBM mainframe background (as a lot of OS/2'ers
> did), and are used to less-than-great things like JCL, then REXX looks
> great. But if you're coming from a Unix background, where good (and
> sometimes wonderful) scripting languages are common, then REXX looks like,
> well, not-so-great.

Must google JCL, I know nothing of it...
> I don't understand this paragraph, but no matter.

No biggie =)
> Do you run it under MS Windows, then?

Sure enough, but under Linux/BSD you wouldn't need it.
> I'm here all week.

Good deal.

--
:wq
Mike Sanders

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> there must be some context you are considering that provides the actual security

Yes, I think I've *just got it* Ben. Let me qualify it by saying
a: it considers only ASCII chars (other chars will simply pass though
as is), & b: my brain hurts...

Hope to roll it all together & post a conclusion probably next week, real life
work awaits just at the present. A quick preview shows I blow no smoke...

# init_map(password): Initializes and returns the substitution map based on
# the provided password. The password influences the ordering of characters
# in the map.
# # sanitize_password(password, base): Sanitizes the provided password by
# removing any character not present in the base character set. It also
# ensures that each character is unique in the sanitized password.
# # mCrypt(str, password, mode): Depending on the mode, it either encodes or
# decodes the input string str using the substitution cipher. Mode 1 is for
# encoding, and Mode 0 is for decoding. The function returns the transformed
# string.
# # The string variable 'base' contains all printable ASCII characters except
# newline ('\n'), which are in the range 32 to 126 inclusive.

--
:wq
Mike Sanders

porkchop@invalid.foo (Mike Sanders) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> there must be some context you are considering that provides the actual security
>
> Yes, I think I've *just got it* Ben. Let me qualify it by saying
> a: it considers only ASCII chars (other chars will simply pass though
> as is), & b: my brain hurts...
>
> Hope to roll it all together & post a conclusion probably next week, real life
> work awaits just at the present. A quick preview shows I blow no smoke...
>
> # init_map(password): Initializes and returns the substitution map based on
> # the provided password. The password influences the ordering of characters
> # in the map.
> #
> # sanitize_password(password, base): Sanitizes the provided password by
> # removing any character not present in the base character set. It also
> # ensures that each character is unique in the sanitized password.
> #
> # mCrypt(str, password, mode): Depending on the mode, it either encodes or
> # decodes the input string str using the substitution cipher. Mode 1 is for
> # encoding, and Mode 0 is for decoding. The function returns the transformed
> # string.
> #
> # The string variable 'base' contains all printable ASCII characters except
> # newline ('\n'), which are in the range 32 to 126 inclusive.

Is this just fun side project or are real data going to be involved?

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Is this just fun side project or are real data going to be involved?

In my case, there is separation of user space & script space.
In other words, httpd with 'awk' as a registered file type,
sits between script & sally:

https://example.io/foo.awk?name=sally?x=1?y=2

Nevertheless if you're thinking what I suspect, you'd be right.

--
:wq
Mike Sanders

On 29.09.2023 21:01, Mike Sanders wrote:
>
> [...] I like system() as its intrinsic to most every awk.

The problem with it is that it's a primitive interface; while
system() per se is ubiquitous in Awk everything you specify as
command(s) in it is system dependent (and thus non-portable).
Personally I avoid it. If I'd have a lot of system() commands
in my Awk code I'd infer that I probably should use the shell
instead (and embed Awk code in shell for specific tasks). And,
further, if there's a lot of shell and a lot of Awk functions
necessary it may be an indication that you need something else
that more thoroughly integrates shell with Awk text processing
functions. GNU Awk's extension libraries may provide some more
system specific functions, and while these are of course also
non-portable you can at least stay withing one (Awk-)tool.
The system() feature allows effectively just to fire up some
command(s) and forget them; no return code, no data exchange,
nothing. E.g.

$ awk 'BEGIN{system("true")}' ; echo $?
0 $ awk 'BEGIN{system("false")}' ; echo $?
0

For your (simple but not well supported) task of redirection
of error messages there might also be other approaches; e.g.
writing error messages into a log-file and displaying these
messages through another process.

awk '{ print "Error:", $0 >> "error.log" ; ... }'
# And in an own window:
tail -f error.log
# This is Unix (maybe DOS supports something similar?)

(Of course I can't tell whether it fits in your context.)

Janis

On 30.09.2023 08:32, Janis Papanagnou wrote:
>
> $ awk 'BEGIN{system("true")}' ; echo $?
> 0
> $ awk 'BEGIN{system("false")}' ; echo $?
> 0

Just noticed, I was wrong on that...

$ awk 'BEGIN{exit(system("true"))}' ; echo $?
0 $ awk 'BEGIN{exit(system("false"))}' ; echo $?
1

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> $ awk 'BEGIN{exit(system("true"))}' ; echo $?
> 0
> $ awk 'BEGIN{exit(system("false"))}' ; echo $?
> 1

Nice, short & sweet, perfect.

My notes below (so far).

hit or miss here, mawk under win is not happy...

win output to stderr: echo This is an error message 1>&2

win busybox awk:

echo | busybox awk '{system("echo stderr message 1>&2")}' 2> err.txt

type err.txt
stderr message

win mawk:

echo | mawk "{system('echo stderr message 1>&2')}"
mawk: could not create a new process (Function not implemented)

notes:

both '&&' and '||' both work in win as we know in nix
nix $SHELL statement separator: ;

win %COMSPEC% statement separator: &

no true/false commands under win, but...

/*

gcc mFalse.c -o mFalse

mFalse
echo %ERRORLEVEL%

*/

int main(void) {return 1;}

// eof

/*

gcc mTrue.c -o mTrue

mTrue
echo %ERRORLEVEL%

*/

int main(void) {return 0;}

// eof

Only speaking for myself, but interesting stuff =)

--
:wq
Mike Sanders