Prev: sed and quoting issue
Next: ssh and passing second arguments through awk
From: Wayne on 11 Aug 2010 16:19
On 8/10/2010 11:50 PM, John Kelly wrote:
> On Wed, 11 Aug 2010 13:31:53 +1000, Ben Finney
> <ben+unix(a)benfinney.id.au> wrote:
>
>> John Kelly <jak(a)isp2dial.com> writes:
>>
>>> Interix has no "mktemp -d" utility.
>>
>> Does the GNU �coreutils� compile for Interix?
>
> Not without a lot of hacking.
>
>
>> That will provide �mktemp� with �-d� feature.
>
> That's what I've used until now, and it's nice. But I need something
> that will work on a barebones Interix system, without coreutils.
>
>
>>> So I thought of reading a few characters from /dev/urandom to get what I
>>> want. But I wonder, is /dev/urandom available on most platforms?
>>
>> The Wikipedia article for �/dev/random� also discusses �/dev/urandom�
>> <URL:http://en.wikipedia.org/wiki//dev/random>, and lists OSen where
>> it's implemented.
>>
>> Generally, if it's not promised by the SUS, it would be caveat
>> implementeur to assume it's on any particular system.
>
> It doesn't need to be universally portable. It just needs to work on
> the platforms I'm interested in.
>
>
>


Maybe you could adapt this script to produce directories instead:

# mktemp.sh - A portable and compliant mktemp replacement.
# Usage: mktemp.sh [ base_file_name ]
#
# (See also the POSIX definition of pathchk utility, the
# rational section, for examples and a discussion of this.)

set -C # turn on noclobber shell option

rand()
{
awk 'BEGIN {srand();printf "%d\n", (rand() * 10^8);}'
}

umask 177

NAME="$1"
NAME="${NAME:=tmp}"

while :
do
TMP=${TMPDIR:-/tmp}/$NAME-$$.$(rand)
# pathchk -p $TMP && > $TMP && break
: > $TMP && break
done

printf "%s\n" "$TMP"


Hope that helps.

--
Wayne
From: Seebs on 11 Aug 2010 16:10
On 2010-08-11, John Kelly <jak(a)isp2dial.com> wrote:
> Maybe, but I don't need to accommodate vintage 1976 systems.

You might find it instructive to find out what the affected systems are
FIRST, and condemn them as irrelevant SECOND. I know, crazy talk.

> Yeah, portability is a time killer.

This is a common belief, but I've found it's mostly not true *if* you
take a small amount of time up front to learn the specs. I write the
bulk of my code to some combination of plain C standards and POSIX, and
as a result, I spend very little time porting anything. Learning a particular
system, then trying to learn to port things, takes a lot more time.

More significantly, perhaps, many "portability" issues turn out to be
just as relevant to the most important system of all: The one you'll be
running in a year or two. Not that long ago, many people considered
robustness in the face of 64-bit pointers to be "irrelevant" on the grounds
that their code only needed to run on x86, not on Alpha. Today, the ability
to run reliably on 64-bit hardware is relevant to x86.

A few years back, I had a desktop which used bash as /bin/sh. The next
release of that operating system no longer used bash as /bin/sh. Meanwhile,
one of my other systems switched from something else to bash. Had I been
writing only to the current shell, I woulda been screwed. Since my .profile
is built to be stable across all the POSIX shells, though, I haven't needed
to make a portability change to it in something over ten years, despite
working in that time on UnixWare, Solaris, a half-dozen Linux varieties,
five major releases of OS X, three of NetBSD, at least one or two of FreeBSD,
and so on...

In all that time, I've had a portability problem with my regular selection
of utilities EXACTLY once, on Cygwin. For a while, Cygwin shipped its
shell with the "getopts" builtin disabled because someone had the belief
that removing that builtin saved significant space, making the shell smaller
and faster. After being told about this excuse a couple of times, I decided
to do some testing, and I went and did the debugging, and timed it.

What I found was that, with the kind of attention to detail I usually
expect from the worshippers of the little tin god, the shell actually still
had all of the code for the getopts builtin; it had been dummied out
from the list of builtin commands, but was still actually present, still
taking up memory, and so on. Re-enabling it had NO measurable effect
on performance at all. The entire thing had been a colossal waste of time.
It's now enabled because it was demonstrated, conclusively, that the
removal had NEVER been benchmarked, verified, tested, or examined or
considered; it was purely an over-enthusiastic attempt to "improve"
performance. (The switch from bash to ash, by contrast, was an INCREDIBLE
performance win, and one I think they were right to make.)

But it was, admittedly, a single real-world case where I had to deal with
a portability issue.

What this means is that, if you have ever had to ask a question about whether
something works on another system, or had a program fail on another system,
you have probably lost more time to portability than I have -- because I did
it right to begin with.

Many thanks to the people who, somewhere over twenty years ago, explained
to me that it was possible for programs to run correctly everywhere.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: John Kelly on 11 Aug 2010 16:50
On Wed, 11 Aug 2010 16:19:03 -0400, Wayne <nospan(a)all.invalid> wrote:

>Maybe you could adapt this script to produce directories instead:
>
># mktemp.sh - A portable and compliant mktemp replacement.
># Usage: mktemp.sh [ base_file_name ]
>#
># (See also the POSIX definition of pathchk utility, the
># rational section, for examples and a discussion of this.)
>
>set -C # turn on noclobber shell option
>
>rand()
>{
> awk 'BEGIN {srand();printf "%d\n", (rand() * 10^8);}'
>}
>
>umask 177
>
>NAME="$1"
>NAME="${NAME:=tmp}"
>
>while :
>do
> TMP=${TMPDIR:-/tmp}/$NAME-$$.$(rand)
># pathchk -p $TMP && > $TMP && break
> : > $TMP && break
>done
>
>printf "%s\n" "$TMP"
>
>
>Hope that helps.

That's interesting. But it looks like it calls awk every time it wants
a new random number. I want to get new random numbers without spawning
an extra subshell for each one.



--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php

From: Ben Bacarisse on 11 Aug 2010 18:56
John Kelly <jak(a)isp2dial.com> writes:

> On Wed, 11 Aug 2010 16:19:03 -0400, Wayne <nospan(a)all.invalid> wrote:
<snip>
>>rand()
>>{
>> awk 'BEGIN {srand();printf "%d\n", (rand() * 10^8);}'
>>}
<snip>
> That's interesting. But it looks like it calls awk every time it wants
> a new random number. I want to get new random numbers without spawning
> an extra subshell for each one.

Weren't you suggesting hexdump a few hours ago? It's not a new subshell
but then nether is awk (usually).

--
Ben.
From: Wayne on 11 Aug 2010 19:22
On 8/11/2010 4:50 PM, John Kelly wrote:
> On Wed, 11 Aug 2010 16:19:03 -0400, Wayne <nospan(a)all.invalid> wrote:
>
>> Maybe you could adapt this script to produce directories instead:
>>
>> # mktemp.sh - A portable and compliant mktemp replacement.
>> # Usage: mktemp.sh [ base_file_name ]
>> #
>> # (See also the POSIX definition of pathchk utility, the
>> # rational section, for examples and a discussion of this.)
>>
>> set -C # turn on noclobber shell option
>>
>> rand()
>> {
>> awk 'BEGIN {srand();printf "%d\n", (rand() * 10^8);}'
>> }
>>
>> umask 177
>>
>> NAME="$1"
>> NAME="${NAME:=tmp}"
>>
>> while :
>> do
>> TMP=${TMPDIR:-/tmp}/$NAME-$$.$(rand)
>> # pathchk -p $TMP && > $TMP && break
>> : > $TMP && break
>> done
>>
>> printf "%s\n" "$TMP"
>>
>>
>> Hope that helps.
>
> That's interesting. But it looks like it calls awk every time it wants
> a new random number. I want to get new random numbers without spawning
> an extra subshell for each one.

The reason for the awk is that this is the only way (that I know of)
in POSIX to get a random number, without writing C code. And even
then the standard is silent on the type and strength of the resulting
random numbers. I suppose it would be possible to whip up a crude
RNG as a shell function, using only shell math. But I doubt that would
be more efficient than using awk.

Of course, if POSIX (SUS) portability doesn't matter, there certainly
are easier ways. Also I imagine the source for Gnu mktemp is available
for download, I doubt you need all of Gnu core utils package just for
that one utility.

I see Stephane CHAZELAS is posting again (yea!), maybe he can come up
with something portable and efficient. (I keep wishing he would
write a O'Reilly book on shell scripting, but I guess he has no
time and/or interest.)

--
Wayne
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: sed and quoting issue
Next: ssh and passing second arguments through awk