info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Any funky scripts to share?
123 views
Skip to first unread message
Mike Sanders
Jan 20, 2018, 4:13:18 PM1/20/18
to
Here's to hoping this post manages a reply or two...
Do any of you have any 'funky looking' scripts,
that despite it all, you still consider handy?
Curious to see what the gurus have cooked up.
Here's one I use allot that looks the part...
#!/bin/sh
[ -t 0 ] || awk '{s[NR]=$0}; \
END{w=length(NR); \
for(c=1; c <= NR; c++) \
printf("%0" w "s %s\n", c, s[c])}'
# eof
<<DOC
numlines - 2018 Michael Sanders
This script numbers lines of input padded
with leading zeros to a uniform width.
usage examples...
numlines < file
echo -e 'x\ny\nz' | numlines
line-by-line annotation follows...
1 #!/bin/sh
2
3 [ -t 0 ] || awk '{s[NR]=$0}; \
4 END{w=length(NR); \
5 for(c=1; c <= NR; c++) \
6 printf("%0" w "s %s\n", c, s[c])}'
7
8 # eof
1 magic line '#!/bin/sh' indicating a shell script.
3 if stdin is not a tty '[ -t 0 ]', stream all input
into awk, where 's[NR]=$0' captures each line '$0'
into associative array 's[]'.
4 after all input is read, record the length of 'NR'
(current number of lines in awk-speak) into variable
'w'. 10 lines, for instance, would be 2 characters
wide. we'll use this value to tell printf the number
of zeros to pad each line of output with.
5 using a for loop starting at 1, till 'c' equals
the total line count represented by 'NR'...
6 output each element of the array prepended with
zeros padded to uniform width using awk's printf
8 end of script
DOC
--
later on,
Mike
https://busybox.hypermart.net
Do any of you have any 'funky looking' scripts,
that despite it all, you still consider handy?
Curious to see what the gurus have cooked up.
Here's one I use allot that looks the part...
#!/bin/sh
[ -t 0 ] || awk '{s[NR]=$0}; \
END{w=length(NR); \
for(c=1; c <= NR; c++) \
printf("%0" w "s %s\n", c, s[c])}'
# eof
<<DOC
numlines - 2018 Michael Sanders
This script numbers lines of input padded
with leading zeros to a uniform width.
usage examples...
numlines < file
echo -e 'x\ny\nz' | numlines
line-by-line annotation follows...
1 #!/bin/sh
2
3 [ -t 0 ] || awk '{s[NR]=$0}; \
4 END{w=length(NR); \
5 for(c=1; c <= NR; c++) \
6 printf("%0" w "s %s\n", c, s[c])}'
7
8 # eof
1 magic line '#!/bin/sh' indicating a shell script.
3 if stdin is not a tty '[ -t 0 ]', stream all input
into awk, where 's[NR]=$0' captures each line '$0'
into associative array 's[]'.
4 after all input is read, record the length of 'NR'
(current number of lines in awk-speak) into variable
'w'. 10 lines, for instance, would be 2 characters
wide. we'll use this value to tell printf the number
of zeros to pad each line of output with.
5 using a for loop starting at 1, till 'c' equals
the total line count represented by 'NR'...
6 output each element of the array prepended with
zeros padded to uniform width using awk's printf
8 end of script
DOC
--
later on,
Mike
https://busybox.hypermart.net
Chris Elvidge
Jan 20, 2018, 6:37:40 PM1/20/18
to
On 20/01/2018 09:13 pm, Mike Sanders wrote:
> This script numbers lines of input padded
> with leading zeros to a uniform width.
why not use 'nl'?
> This script numbers lines of input padded
> with leading zeros to a uniform width.
--
Chris Elvidge, England
Mike Sanders
Jan 20, 2018, 6:54:25 PM1/20/18
to
not always working from a unix-like
OS but have access to awk.
OS but have access to awk.
Allodoxaphobia
Jan 20, 2018, 9:53:35 PM1/20/18
to
On Sat, 20 Jan 2018 21:13:14 +0000 (UTC), Mike Sanders wrote:
>
> This script numbers lines of input padded
> with leading zeros to a uniform width.
heh.... Working with a lot of COBOL programs? :-)
>
> This script numbers lines of input padded
> with leading zeros to a uniform width.
Jonesy
--
Marvin L Jones | Marvin | W3DHJ.net | linux
38.238N 104.547W | @ jonz.net | Jonesy | FreeBSD
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm
Mike Sanders
Jan 21, 2018, 4:28:21 AM1/21/18
to
Allodoxaphobia <knock_you...@example.net> wrote:
> heh.... Working with a lot of COBOL programs? :-)
howdy jonesy
> heh.... Working with a lot of COBOL programs? :-)
chuckle, looks that way now that you point it out.
its just numbering lines that contain parts to be
stored in bins/racks at a salvage yard...
01 1987 chevy blazer windshield
02 1996 ford f150 passenger side door handle
Mike Sanders
Jan 21, 2018, 6:43:30 AM1/21/18
to
Mike Sanders <mi...@porkchop.bsd> wrote:
> Chris Elvidge <ch...@mshome.net> wrote:
>
>> why not use 'nl'?
>
> not always working from a unix-like
> OS but have access to awk.
this screenshot...
> Chris Elvidge <ch...@mshome.net> wrote:
>
>> why not use 'nl'?
>
> not always working from a unix-like
> OS but have access to awk.
<https://busybox.hypermart.net/media/sendto-menu.png>
has an explanation here...
<https://busybox.hypermart.net/run-script-via-sendto-menu.html>
Kaz Kylheku
Jan 21, 2018, 10:14:05 PM1/21/18
to
On 2018-01-20, Mike Sanders <mi...@porkchop.bsd> wrote:
> 6 printf("%0" w "s %s\n", c, s[c])}'
Study printf more closely; like the C printf, it has the *
> 6 printf("%0" w "s %s\n", c, s[c])}'
specifier which means "obtain this value from the next argument":
$ awk 'BEGIN { printf("%0*d\n", 5, 4); }'
00004
Thus we don't have to calculate the format string.
Obviously, less of a big deal in a dynamic interpreter like Awk
compared to C, where string literals turn to static data in
an image (that can even become ROM).
Mike Sanders
Jan 22, 2018, 4:06:41 AM1/22/18
to
Kaz Kylheku <217-67...@kylheku.com> wrote:
> Study printf more closely; like the C printf, it has the *
> specifier which means "obtain this value from the next argument":
>
> $ awk 'BEGIN { printf("%0*d\n", 5, 4); }'
> 00004
>
> Thus we don't have to calculate the format string.
Good catch Kaz, do you have a symlinked 'gawk -> awk'?
> Study printf more closely; like the C printf, it has the *
> specifier which means "obtain this value from the next argument":
>
> $ awk 'BEGIN { printf("%0*d\n", 5, 4); }'
> 00004
>
> Thus we don't have to calculate the format string.
Only gawk & mawk support dynamic width using'%0*', lots
of awk variants don't (found that out the hard way a
few years prior). From the gawk manual:
'Earlier versions of awk did not support this capability.'
<https://www.gnu.org/software/gawk/manual/html_node/Format-Modifiers.html#Format-Modifiers>
We dont have it with vanilla awk in BSD or Busybox.
Fortunately, its only a one time width calculation as coded.
Gotta love the mysteries of printf =)
Kenny McCormack
Jan 22, 2018, 7:07:32 AM1/22/18
to
In article <p449ir$png$1...@news.albasani.net>,
I think it is fair to say that all modern AWKs support it.
And if a version doesn't, then it isn't a modern AWK.
Further, with busybox, you get what you get. Don't get me wrong; I'm a big
fan of busybox - but I'm well aware that the versions of things you get
with busbox is often severely limited as compared to "the real thing".
This is certainly the case with, e.g., the busybox versions of awk and vi.
That all said, there's really nothing wrong with constructing the format
string on-the-fly - there's no practical advantage to doing it the fancy
%*s way. Yes, the later is more "C-like", but that's not a solid reason to
prefer it. In fact, it is not hard to imagine use cases where the %*s
method is a hindrance.
Finally, note that, on Debian (and Debian-like) Linux systems, installing
GAWK "takes over" all the other awk command line variants (including plain
"awk" and "nawk"). This is as it should be.
--
I've been watching cat videos on YouTube. More content and closer to
the truth than anything on Fox.
Mike Sanders <mi...@porkchop.bsd> wrote:
>Kaz Kylheku <217-67...@kylheku.com> wrote:
>
>> Study printf more closely; like the C printf, it has the *
>> specifier which means "obtain this value from the next argument":
>>
>> $ awk 'BEGIN { printf("%0*d\n", 5, 4); }'
>> 00004
>>
>> Thus we don't have to calculate the format string.
>
>Good catch Kaz, do you have a symlinked 'gawk -> awk'?
>Only gawk & mawk support dynamic width using'%0*', lots
>of awk variants don't (found that out the hard way a
>few years prior).
And TAWK (of course)!.
>Kaz Kylheku <217-67...@kylheku.com> wrote:
>
>> Study printf more closely; like the C printf, it has the *
>> specifier which means "obtain this value from the next argument":
>>
>> $ awk 'BEGIN { printf("%0*d\n", 5, 4); }'
>> 00004
>>
>> Thus we don't have to calculate the format string.
>
>Good catch Kaz, do you have a symlinked 'gawk -> awk'?
>Only gawk & mawk support dynamic width using'%0*', lots
>of awk variants don't (found that out the hard way a
>few years prior).
I think it is fair to say that all modern AWKs support it.
And if a version doesn't, then it isn't a modern AWK.
Further, with busybox, you get what you get. Don't get me wrong; I'm a big
fan of busybox - but I'm well aware that the versions of things you get
with busbox is often severely limited as compared to "the real thing".
This is certainly the case with, e.g., the busybox versions of awk and vi.
That all said, there's really nothing wrong with constructing the format
string on-the-fly - there's no practical advantage to doing it the fancy
%*s way. Yes, the later is more "C-like", but that's not a solid reason to
prefer it. In fact, it is not hard to imagine use cases where the %*s
method is a hindrance.
Finally, note that, on Debian (and Debian-like) Linux systems, installing
GAWK "takes over" all the other awk command line variants (including plain
"awk" and "nawk"). This is as it should be.
--
I've been watching cat videos on YouTube. More content and closer to
the truth than anything on Fox.
Allodoxaphobia
Jan 22, 2018, 7:56:54 AM1/22/18
to
On Sat, 20 Jan 2018 21:13:14 +0000 (UTC), Mike Sanders wrote:
> Here's to hoping this post manages a reply or two...
>
> Do any of you have any 'funky looking' scripts,
> that despite it all, you still consider handy?
> Curious to see what the gurus have cooked up.
I have a need" in some of my scripts to detect whether it's running on
>
> Do any of you have any 'funky looking' scripts,
> that despite it all, you still consider handy?
> Curious to see what the gurus have cooked up.
linux or FreeBSD. My ugly hack is to check for my workstation's userid
-- the FreeBSD environ (either my VPS or my web server) being different.
PROD="1";
## Some "production environ" values assigned here
:
:
if [ "${HOME:6:6}" = "jonesy" ] # Development (linux) environment.
then
PROD="0"
## Some "devlopment environ" values assigned here
:
:
fi
There are so many niggly differences between the basic commands of
linux and FreeBSD that knowing where you're running is necessary.
Too, most file paths are WAY different.
But, I'd like to have a universal technique so that I could distribute
some of my scripts without elaborate re-hacking instructions.
Surely I am not the first to need this.
..... using bash.
Mike Sanders
Jan 22, 2018, 8:10:44 AM1/22/18
to
Allodoxaphobia <knock_you...@example.net> wrote:
> I have a need" in some of my scripts to detect whether it's running on
> linux or FreeBSD. My ugly hack is to check for my workstation's userid
> -- the FreeBSD environ (either my VPS or my web server) being different.
Hey Jonesy.
> I have a need" in some of my scripts to detect whether it's running on
> linux or FreeBSD. My ugly hack is to check for my workstation's userid
> -- the FreeBSD environ (either my VPS or my web server) being different.
'uname'?
For instance under OpenBSD, invoking uname emits: 'OpenBSD'...
POSIX: <http://pubs.opengroup.org/onlinepubs/009695399/utilities/uname.html>
FBSD: <https://www.freebsd.org/cgi/man.cgi?query=uname&sektion=1>
Linux: <https://www.systutorials.com/docs/linux/man/1-uname/>
Mike Sanders
Jan 22, 2018, 8:13:42 AM1/22/18
to
Kenny McCormack <gaz...@shell.xmission.com> wrote:
> And TAWK (of course)!.
Knew the awk guru would chime in if awk related =)
> busbox is often severely limited as compared to "the real thing".
Aye. Yet... (hear me out k, I feel you'll understand my
logic) it also forces one to think creatively in order
to solve problems... Certainly, if genuine Coca-Cola
is there for the taking, go for it if so compelled.
But when tasked with working under certain environments
where you're only a hired gun, busybox on a usb stick
is knockout punch that's mighty hard to beat...
<rant>
Most nearly 100% of the time, I can move fluidly between
OSs (Unix or not) with only a few wrenches in my backpocket
vs. lugging around a toolchest on wheels & I like that
ability to pivot quickly. Next is where you'll roll your
eyes at this bumpkin... Though I at times court ksh/bash,
my true sweetheart is the original goodtime girl Ms.
/bin/ash, she's trim, petite & ever loyal.
</rant>
It all works out for me somehow albeit I'm hardheaded.
> And TAWK (of course)!.
Knew the awk guru would chime in if awk related =)
> busbox is often severely limited as compared to "the real thing".
logic) it also forces one to think creatively in order
to solve problems... Certainly, if genuine Coca-Cola
is there for the taking, go for it if so compelled.
But when tasked with working under certain environments
where you're only a hired gun, busybox on a usb stick
is knockout punch that's mighty hard to beat...
<rant>
Most nearly 100% of the time, I can move fluidly between
OSs (Unix or not) with only a few wrenches in my backpocket
vs. lugging around a toolchest on wheels & I like that
ability to pivot quickly. Next is where you'll roll your
eyes at this bumpkin... Though I at times court ksh/bash,
my true sweetheart is the original goodtime girl Ms.
/bin/ash, she's trim, petite & ever loyal.
</rant>
It all works out for me somehow albeit I'm hardheaded.
Kaz Kylheku
Jan 22, 2018, 2:12:41 PM1/22/18
to
On 2018-01-22, Mike Sanders <mi...@porkchop.bsd> wrote:
> Kaz Kylheku <217-67...@kylheku.com> wrote:
>
>> Study printf more closely; like the C printf, it has the *
>> specifier which means "obtain this value from the next argument":
>>
>> $ awk 'BEGIN { printf("%0*d\n", 5, 4); }'
>> 00004
>>
>> Thus we don't have to calculate the format string.
>
> Good catch Kaz, do you have a symlinked 'gawk -> awk'?
> Only gawk & mawk support dynamic width using'%0*', lots
> of awk variants don't (found that out the hard way a
> few years prior). From the gawk manual:
>
> 'Earlier versions of awk did not support this capability.'
It's a POSIX feature.
> Kaz Kylheku <217-67...@kylheku.com> wrote:
>
>> Study printf more closely; like the C printf, it has the *
>> specifier which means "obtain this value from the next argument":
>>
>> $ awk 'BEGIN { printf("%0*d\n", 5, 4); }'
>> 00004
>>
>> Thus we don't have to calculate the format string.
>
> Good catch Kaz, do you have a symlinked 'gawk -> awk'?
> Only gawk & mawk support dynamic width using'%0*', lots
> of awk variants don't (found that out the hard way a
> few years prior). From the gawk manual:
>
> 'Earlier versions of awk did not support this capability.'
"A field width or precision can be specified as the '*' character
instead of a digit string. In this case the next argument from the
expression list shall be fetched and its numeric value taken as the
field width or precision."
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html#tag_20_06_13_10
Legacy systems might be lacking all sorts of stuff.
Jens Schweikhardt
Jan 22, 2018, 3:06:08 PM1/22/18
to
Allodoxaphobia <knock_you...@example.net> wrote
in <slrnp6bnsi.2qun.k...@vps.jonz.net>:
# On Sat, 20 Jan 2018 21:13:14 +0000 (UTC), Mike Sanders wrote:
#> Here's to hoping this post manages a reply or two...
#>
#> Do any of you have any 'funky looking' scripts,
#> that despite it all, you still consider handy?
#> Curious to see what the gurus have cooked up.
#
# I have a need" in some of my scripts to detect whether it's running on
# linux or FreeBSD. My ugly hack is to check for my workstation's userid
# -- the FreeBSD environ (either my VPS or my web server) being different.
The following is the last .profile you'll ever need. It tests for your OS,
shell and hostname and sources the correct files for all permutations.
It has neat separate files for aliases, environment variables, functions
and "rc" code so you always know what file to edit.
You want less instead of more everywhere?
That would go to .aliases.
A zsh completion function that returns a list of installed FreeBSD ports?
That would go to .functions.FreeBSD.zsh.
Setting PATH on your hal9000 box?
That's in .envars.hal9000.
Here is that beast. Enjoy. Hack it. Copy it. Don't sue me.
Jens
# $Id: .profile,v 1.23 2017/12/08 21:10:24 schweikh Exp schweikh $
#
# Must be written using only portable Bourne shell syntax and commands.
# This is why I use "set X" instead of "set --" and `foo` instead of $(foo).
# Leave shell specific customization to appropriate rc files.
#
# .profile is sourced at login by sh and ksh. The zsh sources .zshrc and
# bash sources .bashrc. To get the same behaviour from zsh and bash as well
# I suggest "cd; ln -s .profile .zshrc; ln -s .profile .bashrc".
# Preliminary PATH with programs needed during startup; basically uname.
PATH="/bin:/usr/bin"
# A literal ASCII ESC.
export ESC=' '
# A literal ASCII newline.
export NL="
"
# Control Sequence Introducer.
export CSI="${ESC}["
export reset="${CSI}0m"
export emphasis="${CSI}1m"
export fgBlack="${CSI}30m" bgBlack="${CSI}40m"
export fgRed="${CSI}31m" bgRed="${CSI}41m"
export fgGreen="${CSI}32m" bgGreen="${CSI}42m"
export fgYellow="${CSI}33m" bgYellow="${CSI}43m"
export fgBlue="${CSI}34m" bgBlue="${CSI}44m"
export fgMagenta="${CSI}35m" bgMagenta="${CSI}45m"
export fgCyan="${CSI}36m" bgCyan="${CSI}46m"
export fgWhite="${CSI}37m" bgWhite="${CSI}47m"
export fgDefault="${CSI}39m" bgDefault="${CSI}49m"
echo "$fgWhite~$LOGNAME/.profile$reset" # Announce who is responsible.
# Determine the unqualified hostname.
# shellcheck disable=2086 disable=2121 disable=2039
set X $HOST $HOSTNAME
case $# in
(1)
# shellcheck disable=2121 disable=2046 disable=2006
set X `uname -n 2>/dev/null` `hostname 2>/dev/null` localhost
esac
PROFILE_HOST=${2%%.*}
# Determine what (Bourne compatible) shell we are running under. Put the result
# in $PROFILE_SHELL (not $SHELL) so further code can depend on the shell type.
if test -n "$ZSH_VERSION"; then
PROFILE_SHELL=zsh
elif test -n "$BASH_VERSION"; then
PROFILE_SHELL=bash
elif test -n "$KSH_VERSION"; then
PROFILE_SHELL=ksh
elif test -n "$FCEDIT"; then
PROFILE_SHELL=ksh
elif test -n "$PS3"; then
PROFILE_SHELL=unknown
else
PROFILE_SHELL=sh
fi
# Set PROFILE_OS to a string describing the operating system type.
# The possible PROFILE_OS strings are arbitrary; they are used to
# dispatch to OS specific startup code below. Modify to your liking.
# shellcheck disable=2006
uname="`uname -sr 2>/dev/null`"
case $uname in
(FreeBSD*) PROFILE_OS=FreeBSD;;
(NetBSD*) PROFILE_OS=NetBSD;;
(OpenBSD*) PROFILE_OS=OpenBSD;;
(SunOS\ 4*) PROFILE_OS=SunOS;;
(SunOS\ 5*) PROFILE_OS=Solaris;;
(IRIX*) PROFILE_OS=IRIX;;
(HP*) PROFILE_OS=HP-UX;;
(Linux*) PROFILE_OS=Linux;;
(CYGWIN*) PROFILE_OS=Cygwin;;
(*) PROFILE_OS=generic
echo "warning: cannot map \"$uname\" to an OS string,"
echo "assuming $PROFILE_OS. Edit ~/.profile if this is wrong."
esac
if test "x$HOME" = x; then
HOME=/root # FreeBSD: in single user mode HOME is not set.
export HOME # This makes the /bin/sh read the files in /root.
fi
cd || exit
case $PROFILE_SHELL in
(bash)
echo "This appears to be a$fgCyan Bourne Again Shell (bash)$fgDefault."
;;
(ksh)
echo "This appears to be a$fgCyan Korn Shell (ksh)$fgDefault."
;;
(sh)
echo "This appears to be a$fgCyan Bourne Shell (sh)$fgDefault."
;;
(zsh)
echo "This appears to be a$fgCyan Z-Shell (zsh)$fgDefault."
setopt shwordsplit
;;
(*)
echo "Please add an entry for $PROFILE_SHELL in $HOME/.profile"
esac
#┌─────────────────────────────────────────────────────────────────────────────┐
#│ Set the sequence of initialization: │
#│ The functions are first so that they are usable by other dot files; │
#│ functions, envars and aliases should not produce any output. Commands │
#│ producing output should be executed in rc files. │
#└─────────────────────────────────────────────────────────────────────────────┘
for startup in functions envars aliases rc; do
case $startup in
(rc) say=":";; # Do not announce rc processing (only messes up output).
(*) say="echo"
esac
$say "$fgGreen* Setting up $startup$fgDefault:"
if test -r .$startup; then
$say " - universal (.$startup)"
# shellcheck disable=1090
. "./.$startup"
fi
for variant in \
$PROFILE_OS \
$PROFILE_HOST \
$PROFILE_SHELL \
$PROFILE_OS.$PROFILE_HOST \
$PROFILE_OS.$PROFILE_SHELL \
$PROFILE_HOST.$PROFILE_SHELL \
$PROFILE_OS.$PROFILE_HOST.$PROFILE_SHELL; do
if test -r ".$startup.$variant"; then
$say " - $variant specific (.$startup.$variant)"
# shellcheck disable=1090
. "./.$startup.$variant"
fi
done
done
unset say startup uname variant
export PROFILE_OS PROFILE_HOST PROFILE_SHELL
# vim: syntax=sh tabstop=2 shiftwidth=2 expandtab fileformat=unix
in <slrnp6bnsi.2qun.k...@vps.jonz.net>:
# On Sat, 20 Jan 2018 21:13:14 +0000 (UTC), Mike Sanders wrote:
#> Here's to hoping this post manages a reply or two...
#>
#> Do any of you have any 'funky looking' scripts,
#> that despite it all, you still consider handy?
#> Curious to see what the gurus have cooked up.
#
# I have a need" in some of my scripts to detect whether it's running on
# linux or FreeBSD. My ugly hack is to check for my workstation's userid
# -- the FreeBSD environ (either my VPS or my web server) being different.
The following is the last .profile you'll ever need. It tests for your OS,
shell and hostname and sources the correct files for all permutations.
It has neat separate files for aliases, environment variables, functions
and "rc" code so you always know what file to edit.
You want less instead of more everywhere?
That would go to .aliases.
A zsh completion function that returns a list of installed FreeBSD ports?
That would go to .functions.FreeBSD.zsh.
Setting PATH on your hal9000 box?
That's in .envars.hal9000.
Here is that beast. Enjoy. Hack it. Copy it. Don't sue me.
Jens
# $Id: .profile,v 1.23 2017/12/08 21:10:24 schweikh Exp schweikh $
#
# Must be written using only portable Bourne shell syntax and commands.
# This is why I use "set X" instead of "set --" and `foo` instead of $(foo).
# Leave shell specific customization to appropriate rc files.
#
# .profile is sourced at login by sh and ksh. The zsh sources .zshrc and
# bash sources .bashrc. To get the same behaviour from zsh and bash as well
# I suggest "cd; ln -s .profile .zshrc; ln -s .profile .bashrc".
# Preliminary PATH with programs needed during startup; basically uname.
PATH="/bin:/usr/bin"
# A literal ASCII ESC.
export ESC=' '
# A literal ASCII newline.
export NL="
"
# Control Sequence Introducer.
export CSI="${ESC}["
export reset="${CSI}0m"
export emphasis="${CSI}1m"
export fgBlack="${CSI}30m" bgBlack="${CSI}40m"
export fgRed="${CSI}31m" bgRed="${CSI}41m"
export fgGreen="${CSI}32m" bgGreen="${CSI}42m"
export fgYellow="${CSI}33m" bgYellow="${CSI}43m"
export fgBlue="${CSI}34m" bgBlue="${CSI}44m"
export fgMagenta="${CSI}35m" bgMagenta="${CSI}45m"
export fgCyan="${CSI}36m" bgCyan="${CSI}46m"
export fgWhite="${CSI}37m" bgWhite="${CSI}47m"
export fgDefault="${CSI}39m" bgDefault="${CSI}49m"
echo "$fgWhite~$LOGNAME/.profile$reset" # Announce who is responsible.
# Determine the unqualified hostname.
# shellcheck disable=2086 disable=2121 disable=2039
set X $HOST $HOSTNAME
case $# in
(1)
# shellcheck disable=2121 disable=2046 disable=2006
set X `uname -n 2>/dev/null` `hostname 2>/dev/null` localhost
esac
PROFILE_HOST=${2%%.*}
# Determine what (Bourne compatible) shell we are running under. Put the result
# in $PROFILE_SHELL (not $SHELL) so further code can depend on the shell type.
if test -n "$ZSH_VERSION"; then
PROFILE_SHELL=zsh
elif test -n "$BASH_VERSION"; then
PROFILE_SHELL=bash
elif test -n "$KSH_VERSION"; then
PROFILE_SHELL=ksh
elif test -n "$FCEDIT"; then
PROFILE_SHELL=ksh
elif test -n "$PS3"; then
PROFILE_SHELL=unknown
else
PROFILE_SHELL=sh
fi
# Set PROFILE_OS to a string describing the operating system type.
# The possible PROFILE_OS strings are arbitrary; they are used to
# dispatch to OS specific startup code below. Modify to your liking.
# shellcheck disable=2006
uname="`uname -sr 2>/dev/null`"
case $uname in
(FreeBSD*) PROFILE_OS=FreeBSD;;
(NetBSD*) PROFILE_OS=NetBSD;;
(OpenBSD*) PROFILE_OS=OpenBSD;;
(SunOS\ 4*) PROFILE_OS=SunOS;;
(SunOS\ 5*) PROFILE_OS=Solaris;;
(IRIX*) PROFILE_OS=IRIX;;
(HP*) PROFILE_OS=HP-UX;;
(Linux*) PROFILE_OS=Linux;;
(CYGWIN*) PROFILE_OS=Cygwin;;
(*) PROFILE_OS=generic
echo "warning: cannot map \"$uname\" to an OS string,"
echo "assuming $PROFILE_OS. Edit ~/.profile if this is wrong."
esac
if test "x$HOME" = x; then
HOME=/root # FreeBSD: in single user mode HOME is not set.
export HOME # This makes the /bin/sh read the files in /root.
fi
cd || exit
case $PROFILE_SHELL in
(bash)
echo "This appears to be a$fgCyan Bourne Again Shell (bash)$fgDefault."
;;
(ksh)
echo "This appears to be a$fgCyan Korn Shell (ksh)$fgDefault."
;;
(sh)
echo "This appears to be a$fgCyan Bourne Shell (sh)$fgDefault."
;;
(zsh)
echo "This appears to be a$fgCyan Z-Shell (zsh)$fgDefault."
setopt shwordsplit
;;
(*)
echo "Please add an entry for $PROFILE_SHELL in $HOME/.profile"
esac
#┌─────────────────────────────────────────────────────────────────────────────┐
#│ Set the sequence of initialization: │
#│ The functions are first so that they are usable by other dot files; │
#│ functions, envars and aliases should not produce any output. Commands │
#│ producing output should be executed in rc files. │
#└─────────────────────────────────────────────────────────────────────────────┘
for startup in functions envars aliases rc; do
case $startup in
(rc) say=":";; # Do not announce rc processing (only messes up output).
(*) say="echo"
esac
$say "$fgGreen* Setting up $startup$fgDefault:"
if test -r .$startup; then
$say " - universal (.$startup)"
# shellcheck disable=1090
. "./.$startup"
fi
for variant in \
$PROFILE_OS \
$PROFILE_HOST \
$PROFILE_SHELL \
$PROFILE_OS.$PROFILE_HOST \
$PROFILE_OS.$PROFILE_SHELL \
$PROFILE_HOST.$PROFILE_SHELL \
$PROFILE_OS.$PROFILE_HOST.$PROFILE_SHELL; do
if test -r ".$startup.$variant"; then
$say " - $variant specific (.$startup.$variant)"
# shellcheck disable=1090
. "./.$startup.$variant"
fi
done
done
unset say startup uname variant
export PROFILE_OS PROFILE_HOST PROFILE_SHELL
# vim: syntax=sh tabstop=2 shiftwidth=2 expandtab fileformat=unix
Allodoxaphobia
Jan 22, 2018, 9:46:30 PM1/22/18
to
On Mon, 22 Jan 2018 13:10:40 +0000 (UTC), Mike Sanders wrote:
> Allodoxaphobia <knock_you...@example.net> wrote:
>
>> I have a need" in some of my scripts to detect whether it's running on
>> linux or FreeBSD. My ugly hack is to check for my workstation's userid
>> -- the FreeBSD environ (either my VPS or my web server) being different.
>
> Hey Jonesy.
>
> 'uname'?
>
> For instance under OpenBSD, invoking uname emits: 'OpenBSD'...
Right. Ya, butt... There might be many different unames!
> Allodoxaphobia <knock_you...@example.net> wrote:
>
>> I have a need" in some of my scripts to detect whether it's running on
>> linux or FreeBSD. My ugly hack is to check for my workstation's userid
>> -- the FreeBSD environ (either my VPS or my web server) being different.
>
> Hey Jonesy.
>
> 'uname'?
>
> For instance under OpenBSD, invoking uname emits: 'OpenBSD'...
I dunno if I can rely on all linuxes emitting "linux ....."
Then there's IBM AIX, HP-UX, Solaris SPARC, ....
The decision logic could be a rather bulky hack.
But, I would want to focus on/support just linux and (Free)BSD.
With other installation of my scripts it would up to the installer
to fixup/re-hack.
I keep looking for the one "tell" in the environment that I could
hang my hat on -- but nothing jumps out at me.
One test could be `which bash`. But, I'll bet that's not cast in
concrete in all places....
Thanks, Mike!
Jonesy
Mike Sanders
Jan 23, 2018, 7:23:16 AM1/23/18
to
Allodoxaphobia <knock_you...@example.net> wrote:
> Right. Ya, butt... There might be many different unames!
No sweat, you got this covered, hang tough Jonesy =)
> Right. Ya, butt... There might be many different unames!
# tip: note the asterisk* below
unameOS="$(uname -s | tr 'A-Z' 'a-z')"
case "${unameOS}" in
aix*) boxen=AIX;;
cygwin*) boxen=Cygwin;;
darwin*) boxen=Mac;;
freebsd*) boxen=FreeBSD;;
hp-ux*) boxen=HP-UX;;
irix*) boxen=IRIX;;
linux*) boxen=Linux;;
mingw*) boxen=MinGw;;
minix*) boxen=Minix;;
netbsd*) boxen=NetBSD;;
openbsd*) boxen=OpenBSD;;
qnx*) boxen=QNX;;
sunos*) boxen=SunOS;;
windows*) boxen=Windows;;
*) boxen="UNKNOWN:${unameOS}"
esac
echo ${boxen}
# for a confirmed working list see also:
# <https://en.wikipedia.org/wiki/Uname#Examples>
# eof
> I keep looking for the one "tell" in the environment
> that I could hang my hat on -- but nothing jumps out at me.
GETOS="$(echo $OSTYPE | tr 'A-Z' 'a-z')"
case "${GETOS}" in
darwin*) function_mac;;
freebsd*) function_fbsd;;
linux*) function_linux;;
*) echo unknown OS; exit 1;;
esac
Don't give up - that's not the way to win, besides...
what doesn't kill us only serves to make us stronger.
Mike Sanders
Jan 23, 2018, 8:03:07 AM1/23/18
to
Jonesy: Checkout Jen's work shown below
& upthread, lots of really ideas to chew on IMO.
> export ESC='^['
> #???????????????????????????????????????????????????????????????????????????????
> #? Set the sequence of initialization: ?
> #? The functions are first so that they are usable by other dot files; ?
> #? functions, envars and aliases should not produce any output. Commands ?
> #? producing output should be executed in rc files. ?
> #???????????????????????????????????????????????????????????????????????????????
& upthread, lots of really ideas to chew on IMO.
> #? Set the sequence of initialization: ?
> #? The functions are first so that they are usable by other dot files; ?
> #? functions, envars and aliases should not produce any output. Commands ?
> #? producing output should be executed in rc files. ?
> #???????????????????????????????????????????????????????????????????????????????
Kaz Kylheku
Jan 23, 2018, 4:16:55 PM1/23/18
to
On 2018-01-23, Allodoxaphobia <knock_you...@example.net> wrote:
> On Mon, 22 Jan 2018 13:10:40 +0000 (UTC), Mike Sanders wrote:
>> Allodoxaphobia <knock_you...@example.net> wrote:
>>
>>> I have a need" in some of my scripts to detect whether it's running on
>>> linux or FreeBSD. My ugly hack is to check for my workstation's userid
>>> -- the FreeBSD environ (either my VPS or my web server) being different.
>>
>> Hey Jonesy.
>>
>> 'uname'?
>>
>> For instance under OpenBSD, invoking uname emits: 'OpenBSD'...
>
> Right. Ya, butt... There might be many different unames!
> I dunno if I can rely on all linuxes emitting "linux ....."
The uname command relies on the uname C library function.
> On Mon, 22 Jan 2018 13:10:40 +0000 (UTC), Mike Sanders wrote:
>> Allodoxaphobia <knock_you...@example.net> wrote:
>>
>>> I have a need" in some of my scripts to detect whether it's running on
>>> linux or FreeBSD. My ugly hack is to check for my workstation's userid
>>> -- the FreeBSD environ (either my VPS or my web server) being different.
>>
>> Hey Jonesy.
>>
>> 'uname'?
>>
>> For instance under OpenBSD, invoking uname emits: 'OpenBSD'...
>
> Right. Ya, butt... There might be many different unames!
> I dunno if I can rely on all linuxes emitting "linux ....."
On GNU/Linux systems, and most unix-like systems, it's a system call
into the kernel.
The "sysname" field in the "struct utsname" structure is quite
consistent across GNU/Linux distros, I think; it's driven by the
kernel. Not reporting "Linux" as the "sysname" would break
things; it would be a bad idea afor any GNU/Linux distro to patch that
to be otherwise.
> Then there's IBM AIX, HP-UX, Solaris SPARC, ....
> The decision logic could be a rather bulky hack.
this in the first place, rather than being portable?
Kaz Kylheku
Jan 23, 2018, 4:20:10 PM1/23/18
to
On 2018-01-23, Mike Sanders <mi...@porkchop.bsd> wrote:
> Allodoxaphobia <knock_you...@example.net> wrote:
>
>> Right. Ya, butt... There might be many different unames!
>
> No sweat, you got this covered, hang tough Jonesy =)
>
> # tip: note the asterisk* below
>
> unameOS="$(uname -s | tr 'A-Z' 'a-z')"
You're better off just using "$(uname -s)" and matching exactly,
> Allodoxaphobia <knock_you...@example.net> wrote:
>
>> Right. Ya, butt... There might be many different unames!
>
> No sweat, you got this covered, hang tough Jonesy =)
>
> # tip: note the asterisk* below
>
> unameOS="$(uname -s | tr 'A-Z' 'a-z')"
and not adding any sort of gratuitous mangling.
The suspicion that these vendors will randomly flip the case
of the "sysname" field of "struct utsname" between releases
is not justified.
If the suspicion *is* justified for some specific vendor, then handle
that in their particular case, e.g.
case ....
FooblyOS | fooblyOS ) boxen= ...;
Thomas 'PointedEars' Lahn
Jan 23, 2018, 9:57:27 PM1/23/18
to
Kaz Kylheku wrote:
> case ....
> FooblyOS | fooblyOS ) boxen= ...;
It is just an example, but it should be noted that, because the “case”
> case ....
> FooblyOS | fooblyOS ) boxen= ...;
command uses *pathname* expansion,
case ....
[Ff]ooblyOS) boxen= ...;
is a possibility, too.
--
PointedEars
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2
Please do not cc me. /Bitte keine Kopien per E-Mail.
Mike Sanders
Jan 24, 2018, 7:27:46 AM1/24/18
to
Kaz Kylheku <217-67...@kylheku.com> wrote:
> You're better off just using "$(uname -s)" and matching exactly,
> and not adding any sort of gratuitous mangling.
>
> The suspicion that these vendors will randomly flip the case
> of the "sysname" field of "struct utsname" between releases
> is not justified.
Indisputably rock-solid advice Kaz, but why not account
> You're better off just using "$(uname -s)" and matching exactly,
> and not adding any sort of gratuitous mangling.
>
> The suspicion that these vendors will randomly flip the case
> of the "sysname" field of "struct utsname" between releases
> is not justified.
for the proprietary hybrids (neither fully POSIX, or
fully Linux) out in the wild too? Consider the cheapie
$30.USD tablet Acer Iconia...
Assuming this overlay: <https://goo.gl/VwA6F>
uname -s emits: LinuxACERXXX
where 'XXX' is either a custom kernel version &/or
modal number (no doubt a cocked up 'droid variant of
some sort). Now before anyone says 'yeah but'... Here,
*I'm* not going to assume we're *only* running on a PC
or notebook. In fact, there's more Linux running in
folks back pockets nowadays with the rise of mobile
than any other form factor... see also [1]
That's my story & I'm sticking to it =) Having said all
that, in my admittedly newbie thinking, Kaz is correct,
when it comes to *standard* distros.
The way forward for Jonesy (if it were me) would be to
distribute his scripts exclusively in dash (debian ash)
for portability because:
. defacto /bin/sh on most Linux distros, BSDs, Busybox, etc[2]
. used on lots of embedded systems[3]
. about 4x faster than bash[4]
. plain jane, no fuss, good old 'sh'[5]
notes:
1. off topic but very neat: <https://goo.gl/5SQO6>
2. <https://goo.gl/E6fHcm>
3. <https://goo.gl/7nUuiD>
4. <https://goo.gl/wkTX6N>
5. <https://goo.gl/7goxUL>
Kaz Kylheku
Jan 24, 2018, 8:58:22 AM1/24/18
to
On 2018-01-23, Kaz Kylheku <217-67...@kylheku.com> wrote:
> On 2018-01-23, Mike Sanders <mi...@porkchop.bsd> wrote:
>> Allodoxaphobia <knock_you...@example.net> wrote:
>>
>>> Right. Ya, butt... There might be many different unames!
>>
>> No sweat, you got this covered, hang tough Jonesy =)
>>
>> # tip: note the asterisk* below
>>
>> unameOS="$(uname -s | tr 'A-Z' 'a-z')"
>
> You're better off just using "$(uname -s)" and matching exactly,
> and not adding any sort of gratuitous mangling.
Sorry, I didn't mean "drop the *" for the prefix match.
> On 2018-01-23, Mike Sanders <mi...@porkchop.bsd> wrote:
>> Allodoxaphobia <knock_you...@example.net> wrote:
>>
>>> Right. Ya, butt... There might be many different unames!
>>
>> No sweat, you got this covered, hang tough Jonesy =)
>>
>> # tip: note the asterisk* below
>>
>> unameOS="$(uname -s | tr 'A-Z' 'a-z')"
>
> You're better off just using "$(uname -s)" and matching exactly,
> and not adding any sort of gratuitous mangling.
That is essential; matching "exactly" won't work on most
of the systems in your example.
E.g. Cygwin's sysname is something like "CYGWIN_NT-6.1".
Kenny McCormack
Jan 24, 2018, 2:56:39 PM1/24/18
to
In article <201801240...@kylheku.com>,
I don't think there is anything *wrong* with doing a case-insensitve match.
Admitedly, you're not likely to hit someone spelling it "liNuX", but
certainly the world is chaotic enough that some will write "linux" and
others might write "Linux". I mean, it is pretty clear to the human
observer that both are obviously referring to some version of Linux, so why
not make the program handle it as well. It doesn't really cost anything.
In fact, maybe you should be matching on *linux* - since who knows what
some idiot might do - the point is anything containing the string "linux"
(regardless of case) is probably, well, linux.
--
https://en.wikipedia.org/wiki/Mansplaining
It describes comp.lang.c to a T!
Admitedly, you're not likely to hit someone spelling it "liNuX", but
certainly the world is chaotic enough that some will write "linux" and
others might write "Linux". I mean, it is pretty clear to the human
observer that both are obviously referring to some version of Linux, so why
not make the program handle it as well. It doesn't really cost anything.
In fact, maybe you should be matching on *linux* - since who knows what
some idiot might do - the point is anything containing the string "linux"
(regardless of case) is probably, well, linux.
--
https://en.wikipedia.org/wiki/Mansplaining
It describes comp.lang.c to a T!
Helmut Waitzmann
Jan 24, 2018, 6:05:13 PM1/24/18
to
Thomas 'PointedEars' Lahn <Point...@web.de>:
The rationale ist not exactly correct. The "case" compound
command uses pattern matching
(<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
rather than pathname expansion.
When pattern matching notation is used for pathname expansion, the
pattern matching rules are qualified by additional rules
(<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03>)
regarding the slash character in a pathname and the period
character at the beginning of a filename.
For example, the commands
var=/dev/null &&
case "$var" in
/dev?null)
printf '%s\n' "$var";;
esac
will output "/dev/null", while the command
printf '%s\n' /dev?null
won't output "/dev/null", even if the file "/dev/null" happens
to exist.
> Kaz Kylheku wrote:
>
>> case ....
>> FooblyOS | fooblyOS ) boxen= ...;
>
> It is just an example, but it should be noted that, because the “case”
> command uses *pathname* expansion,
>
> case ....
> [Ff]ooblyOS) boxen= ...;
>
> is a possibility, too.
Yes, exactly.
>
>> case ....
>> FooblyOS | fooblyOS ) boxen= ...;
>
> It is just an example, but it should be noted that, because the “case”
> command uses *pathname* expansion,
>
> case ....
> [Ff]ooblyOS) boxen= ...;
>
> is a possibility, too.
The rationale ist not exactly correct. The "case" compound
command uses pattern matching
(<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
rather than pathname expansion.
When pattern matching notation is used for pathname expansion, the
pattern matching rules are qualified by additional rules
(<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03>)
regarding the slash character in a pathname and the period
character at the beginning of a filename.
For example, the commands
var=/dev/null &&
case "$var" in
/dev?null)
printf '%s\n' "$var";;
esac
will output "/dev/null", while the command
printf '%s\n' /dev?null
won't output "/dev/null", even if the file "/dev/null" happens
to exist.
Thomas 'PointedEars' Lahn
Jan 24, 2018, 7:07:13 PM1/24/18
to
Helmut Waitzmann wrote:
> Thomas 'PointedEars' Lahn <Point...@web.de>:
>> Kaz Kylheku wrote:
>>> case ....
>>> FooblyOS | fooblyOS ) boxen= ...;
>>
>> It is just an example, but it should be noted that, because the “case”
>> command uses *pathname* expansion,
>>
>> case ....
>> [Ff]ooblyOS) boxen= ...;
>>
>> is a possibility, too.
>
> Yes, exactly.
>
> The rationale ist not exactly correct. The "case" compound
> command uses pattern matching
>
(<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
> rather than pathname expansion.
,-[bash(1)]
> Thomas 'PointedEars' Lahn <Point...@web.de>:
>> Kaz Kylheku wrote:
>>> case ....
>>> FooblyOS | fooblyOS ) boxen= ...;
>>
>> It is just an example, but it should be noted that, because the “case”
>> command uses *pathname* expansion,
>>
>> case ....
>> [Ff]ooblyOS) boxen= ...;
>>
>> is a possibility, too.
>
> Yes, exactly.
>
> The rationale ist not exactly correct. The "case" compound
> command uses pattern matching
>
(<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
> rather than pathname expansion.
|
| […]
| case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac
| A case command first expands word, and tries to match it
| against each pattern in turn, using the same matching rules
| as for path name expansion (see Pathname Expansion below).
| […]
Mike Sanders
Jan 25, 2018, 7:24:02 AM1/25/18
to
Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In fact, maybe you should be matching on *linux* - since who knows what
> some idiot might do - the point is anything containing the string "linux"
> (regardless of case) is probably, well, linux.
Common sense prevails...
> In fact, maybe you should be matching on *linux* - since who knows what
> some idiot might do - the point is anything containing the string "linux"
> (regardless of case) is probably, well, linux.
A single 'tr' covers alot of unintentional finger flubs.
Well worth the cost imo:
*freebsd*
FreeBSD
Freebsd
freeBSD
freebsd
FREEBSD
fReEbSd...
Helmut Waitzmann
Jan 25, 2018, 10:24:42 AM1/25/18
to
Thomas 'PointedEars' Lahn <Point...@web.de>:
“using the same matching rules as for path name expansion”
is not the same as “using path name expansion”.
The “matching rules as for path name expansion” are defined in the
subsection “Pattern Matching” of the section “Pathname Expansion”
of the bash(1) manual page:
Pattern Matching
Any character that appears in a pattern, other than the
special pattern characters described below, matches
itself. The NUL character may not occur in a pattern.
A backslash escapes the following character; the escap‐
ing backslash is discarded when matching. The special
pattern characters must be quoted if they are to be
matched literally.
The special pattern characters have the following mean‐
ings:
* Matches any string, including the null string.
When the globstar shell option is enabled, and *
is used in a pathname expansion context, two
adjacent *s used as a single pattern will match
all files and zero or more directories and sub‐
directories. If followed by a /, two adjacent
*s will match only directories and subdirecto‐
ries.
? Matches any single character.
[...] Matches any one of the enclosed characters. A
pair of characters separated by a hyphen denotes
a range expression; any character that sorts
between those two characters, inclusive, using
the current locale's collating sequence and
character set, is matched. If the first charac‐
ter following the [ is a ! or a ^ then any
character not enclosed is matched. The sorting
order of characters in range expressions is
determined by the current locale and the value
of the LC_COLLATE shell variable, if set. A -
may be matched by including it as the first or
last character in the set. A ] may be matched
by including it as the first character in the
set.
[…]
Also the two command lines I gave reinforce the difference between
Pathname Expansion and Pattern Matching.
> Helmut Waitzmann wrote:
>
>> Thomas 'PointedEars' Lahn <Point...@web.de>:
>>> Kaz Kylheku wrote:
>>>> case ....
>>>> FooblyOS | fooblyOS ) boxen= ...;
>>>
>>> It is just an example, but it should be noted that, because the “case”
>>> command uses *pathname* expansion,
>>>
>>> case ....
>>> [Ff]ooblyOS) boxen= ...;
>>>
>>> is a possibility, too.
>>
>> Yes, exactly.
>>
>> The rationale ist not exactly correct. The "case" compound
>> command uses pattern matching
>>
> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
>> rather than pathname expansion.
>
> ,-[bash(1)]
> |
> | […]
> | case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac
> | A case command first expands word, and tries to match it
> | against each pattern in turn, using the same matching rules
> | as for path name expansion (see Pathname Expansion below).
> | […]
Thank you for quoting the bash(1) manual page.
>
>> Thomas 'PointedEars' Lahn <Point...@web.de>:
>>> Kaz Kylheku wrote:
>>>> case ....
>>>> FooblyOS | fooblyOS ) boxen= ...;
>>>
>>> It is just an example, but it should be noted that, because the “case”
>>> command uses *pathname* expansion,
>>>
>>> case ....
>>> [Ff]ooblyOS) boxen= ...;
>>>
>>> is a possibility, too.
>>
>> Yes, exactly.
>>
>> The rationale ist not exactly correct. The "case" compound
>> command uses pattern matching
>>
> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
>> rather than pathname expansion.
>
> ,-[bash(1)]
> |
> | […]
> | case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac
> | A case command first expands word, and tries to match it
> | against each pattern in turn, using the same matching rules
> | as for path name expansion (see Pathname Expansion below).
> | […]
“using the same matching rules as for path name expansion”
is not the same as “using path name expansion”.
The “matching rules as for path name expansion” are defined in the
subsection “Pattern Matching” of the section “Pathname Expansion”
of the bash(1) manual page:
Pattern Matching
Any character that appears in a pattern, other than the
special pattern characters described below, matches
itself. The NUL character may not occur in a pattern.
A backslash escapes the following character; the escap‐
ing backslash is discarded when matching. The special
pattern characters must be quoted if they are to be
matched literally.
The special pattern characters have the following mean‐
ings:
* Matches any string, including the null string.
When the globstar shell option is enabled, and *
is used in a pathname expansion context, two
adjacent *s used as a single pattern will match
all files and zero or more directories and sub‐
directories. If followed by a /, two adjacent
*s will match only directories and subdirecto‐
ries.
? Matches any single character.
[...] Matches any one of the enclosed characters. A
pair of characters separated by a hyphen denotes
a range expression; any character that sorts
between those two characters, inclusive, using
the current locale's collating sequence and
character set, is matched. If the first charac‐
ter following the [ is a ! or a ^ then any
character not enclosed is matched. The sorting
order of characters in range expressions is
determined by the current locale and the value
of the LC_COLLATE shell variable, if set. A -
may be matched by including it as the first or
last character in the set. A ] may be matched
by including it as the first character in the
set.
[…]
Also the two command lines I gave reinforce the difference between
Pathname Expansion and Pattern Matching.
Jens Schweikhardt
Jan 25, 2018, 1:04:56 PM1/25/18
to
Mike Sanders <mi...@porkchop.bsd> wrote
in <p4ci8r$e21$1...@news.albasani.net>:
# Kenny McCormack <gaz...@shell.xmission.com> wrote:
#
#> In fact, maybe you should be matching on *linux* - since who knows what
#> some idiot might do - the point is anything containing the string "linux"
#> (regardless of case) is probably, well, linux.
#
# Common sense prevails...
#
# A single 'tr' covers alot of unintentional finger flubs.
# Well worth the cost imo:
#
# *freebsd*
# FreeBSD
# Freebsd
# freeBSD
# freebsd
# FREEBSD
# fReEbSd...
If the cost is a useless pipe and fork to tr(1), that's unacceptable. For
one thing, FreeBSD has always and will always be spelled/spelt that way.
I know this because me and my colleagues are taking care of it.
For your random Linux distro du jour you use
case $uname in
(*[Ll][Ii][Nn][Uu][Xx]*) PROFILE_OS=Linux;;
esac
to defeat a silly marketing's branding idea and be done with it.
Is there really any distro out there where "uname -s" is not "Linux"?
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
in <p4ci8r$e21$1...@news.albasani.net>:
# Kenny McCormack <gaz...@shell.xmission.com> wrote:
#
#> In fact, maybe you should be matching on *linux* - since who knows what
#> some idiot might do - the point is anything containing the string "linux"
#> (regardless of case) is probably, well, linux.
#
# Common sense prevails...
#
# A single 'tr' covers alot of unintentional finger flubs.
# Well worth the cost imo:
#
# *freebsd*
# FreeBSD
# Freebsd
# freeBSD
# freebsd
# FREEBSD
# fReEbSd...
If the cost is a useless pipe and fork to tr(1), that's unacceptable. For
one thing, FreeBSD has always and will always be spelled/spelt that way.
I know this because me and my colleagues are taking care of it.
For your random Linux distro du jour you use
case $uname in
(*[Ll][Ii][Nn][Uu][Xx]*) PROFILE_OS=Linux;;
esac
to defeat a silly marketing's branding idea and be done with it.
Is there really any distro out there where "uname -s" is not "Linux"?
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Kaz Kylheku
Jan 25, 2018, 1:41:21 PM1/25/18
to
On 2018-01-24, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In fact, maybe you should be matching on *linux* - since who knows what
> some idiot might do - the point is anything containing the string "linux"
> (regardless of case) is probably, well, linux.
Since the scope of what idiots may do is unbounded, why not match
> In fact, maybe you should be matching on *linux* - since who knows what
> some idiot might do - the point is anything containing the string "linux"
> (regardless of case) is probably, well, linux.
on *, know what I mean?
Kaz Kylheku
Jan 25, 2018, 2:01:32 PM1/25/18
to
On 2018-01-25, Jens Schweikhardt <use...@schweikhardt.net> wrote:
> Mike Sanders <mi...@porkchop.bsd> wrote
> in <p4ci8r$e21$1...@news.albasani.net>:
> # Kenny McCormack <gaz...@shell.xmission.com> wrote:
> #
> #> In fact, maybe you should be matching on *linux* - since who knows what
> #> some idiot might do - the point is anything containing the string "linux"
> #> (regardless of case) is probably, well, linux.
> #
> # Common sense prevails...
> #
> # A single 'tr' covers alot of unintentional finger flubs.
> # Well worth the cost imo:
> #
> # *freebsd*
> # FreeBSD
> # Freebsd
> # freeBSD
> # freebsd
> # FREEBSD
> # fReEbSd...
>
> If the cost is a useless pipe and fork to tr(1), that's unacceptable. For
I looked at the case and though, "hey, that looks broken; the "struct
> Mike Sanders <mi...@porkchop.bsd> wrote
> in <p4ci8r$e21$1...@news.albasani.net>:
> # Kenny McCormack <gaz...@shell.xmission.com> wrote:
> #
> #> In fact, maybe you should be matching on *linux* - since who knows what
> #> some idiot might do - the point is anything containing the string "linux"
> #> (regardless of case) is probably, well, linux.
> #
> # Common sense prevails...
> #
> # A single 'tr' covers alot of unintentional finger flubs.
> # Well worth the cost imo:
> #
> # *freebsd*
> # FreeBSD
> # Freebsd
> # freeBSD
> # freebsd
> # FREEBSD
> # fReEbSd...
>
> If the cost is a useless pipe and fork to tr(1), that's unacceptable. For
utsname" structure contains "Linux" not "linux".
Then I looked above and saw the gratuitous case folding that makes
it work.
That is the cost: attracting the eyes of reviewers to false alarms.
When coding anything, don't go out of your way to make anything look
wrong that isn't wrong.
Kaz Kylheku
Jan 25, 2018, 2:21:38 PM1/25/18
to
On 2018-01-24, Helmut Waitzmann <nn.th...@xoxy.net> wrote:
> Thomas 'PointedEars' Lahn <Point...@web.de>:
>> Kaz Kylheku wrote:
>>
>>> case ....
>>> FooblyOS | fooblyOS ) boxen= ...;
>>
>> It is just an example, but it should be noted that, because the “case”
>> command uses *pathname* expansion,
>>
>> case ....
>> [Ff]ooblyOS) boxen= ...;
>>
>> is a possibility, too.
>
> Yes, exactly.
>
> The rationale ist not exactly correct. The "case" compound
> command uses pattern matching
> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
> rather than pathname expansion.
>
> When pattern matching notation is used for pathname expansion, the
> pattern matching rules are qualified by additional rules
> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03>)
> regarding the slash character in a pathname and the period
> character at the beginning of a filename.
The rules are basically the same, but the glob function applies matching
> Thomas 'PointedEars' Lahn <Point...@web.de>:
>> Kaz Kylheku wrote:
>>
>>> case ....
>>> FooblyOS | fooblyOS ) boxen= ...;
>>
>> It is just an example, but it should be noted that, because the “case”
>> command uses *pathname* expansion,
>>
>> case ....
>> [Ff]ooblyOS) boxen= ...;
>>
>> is a possibility, too.
>
> Yes, exactly.
>
> The rationale ist not exactly correct. The "case" compound
> command uses pattern matching
> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
> rather than pathname expansion.
>
> When pattern matching notation is used for pathname expansion, the
> pattern matching rules are qualified by additional rules
> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03>)
> regarding the slash character in a pathname and the period
> character at the beginning of a filename.
to components, not to entire paths.
It's something like: the pattern is broken into components as if it
were a path, so */* becomes *two* patterns "*" and "*", understood to be
relative to cwd.
After this breaking, the slash doesn't occur in any pattern.
Glob then knows it's searching two levels deep in the
directory space.
How can that work? Basically, do a directory traversal as usual, while
also maintaining a stack context which points into the pattern.
If processing a*/b* for instance, the top level search applies
the a* pattern to everything it sees, and then the level below that
applies b* to whatever *it* sees.
> For example, the commands
>
> var=/dev/null &&
> case "$var" in
> /dev?null)
> printf '%s\n' "$var";;
> esac
>
> will output "/dev/null", while the command
>
> printf '%s\n' /dev?null
>
> won't output "/dev/null", even if the file "/dev/null" happens
> to exist.
containing one component, so just the / directory is searched for
entries matching dev?null.
However, I suspect that the ? wildcard might actually match a slash
character under file globbing if you somehow manage to get that slash
character into the filesystem.
Let's try this exercise, on Linux. I prepared a file called "dummyfs"
which is an ext2 filesystem in which I created an empty file called
fooXbar. I then edited the image to change fooXbar to foo/bar
and mounted:
0:terada:~/test$ sudo mount -o loop -t ext2 dummyfs ./mnt
0:terada:~/test$ cd mnt/
0:terada:~/test/mnt$ ls -l
ls: cannot access 'foo/bar': No such file or directory
total 12
-????????? ? ? ? ? ? foo/bar
drwx------ 2 root root 12288 Jan 25 11:13 lost+found
1:terada:~/test/mnt$ echo foo?bar
foo?bar
0:terada:~/test/mnt$ echo foo*bar
foo/bar
So bash's ? refused to match a slash, but at least * obliged.
Now let's try the glibc glob function:
0:terada:~/test/mnt$ txr
This is the TXR Lisp interactive listener of TXR 188.
Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet.
1> (glob "foo?bar")
("foo/bar")
2> (glob "foo*bar")
("foo/bar")
I'm rather surprised by bash than by glob.
Mike Sanders
Jan 25, 2018, 3:19:49 PM1/25/18
to
Jens Schweikhardt <use...@schweikhardt.net> wrote:
> If the cost is a useless pipe and fork to tr(1), that's unacceptable.
For you perhaps. For me? Not at all & I'll use it as is.
> If the cost is a useless pipe and fork to tr(1), that's unacceptable.
> For one thing, FreeBSD has always and will always be spelled/spelt that way.
> I know this because me and my colleagues are taking care of it.
The margin of error increases with the complexity of the string...
...*for the person writing the script*
The 'tr' is there to help the script writer only, who may not
know the correct output because they don't have access to said
OS yet still wishes to distribute their script for that platform.
But now that you mention it, I sort of did feel it would make
a great conspiracy...
> For your random Linux distro du jour you use
>
> case $uname in
> (*[Ll][Ii][Nn][Uu][Xx]*) PROFILE_OS=Linux;;
> esac
at that 'new guy' there's no sense in it. Its unnecessary
*word salad*.
The entire point is to...
echo 'AaVvOoIiDd CcOoMmPpLlEeXxIiTtYy' | tr -d 'A-Z'
Hello?
In fact, we can measure[i] the amount of entropy[ii]
of your string vs. my string (pre-globbing of course,
which if expanded, only *worsens* the problem):
Jens '(*[Ll][Ii][Nn][Uu][Xx]*) PROFILE_OS': 4.2373
Mike '*linux*PROFILE_OS': 3.85217
You can plainly measure this for yourself & see I've no
axe to grind. Now, if *you* want increased complexity in
order to simply win an argument Jens, well, I guess that's
fine, but *I* do not.
> to defeat a silly marketing's branding idea and be done with it.
> Is there really any distro out there where "uname -s" is not "Linux"?
is a traditional computer folks & I wont work to convince you so.
Seems to me your choices are:
1. believe it
2. deny it
3. root a device & test for yourself (though who knows if
your device has such string)
Dunno what else to say...
notes:
i. https://rosettacode.org/wiki/Entropy#AWK
ii. my rough definition is: 'lack of order or predictability;
gradual decline into disorder; deterioration'
Jens Schweikhardt
Jan 25, 2018, 4:15:47 PM1/25/18
to
Mike Sanders <mi...@porkchop.bsd> wrote
in <p4de4v$aof$1...@news.albasani.net>:
...
# In fact, we can measure[i] the amount of entropy[ii]
# of your string vs. my string (pre-globbing of course,
# which if expanded, only *worsens* the problem):
#
#
# Jens '(*[Ll][Ii][Nn][Uu][Xx]*) PROFILE_OS': 4.2373
#
# Mike '*linux*PROFILE_OS': 3.85217
Where is the entropy for the tr A-Z conversion? For a meaningful
comparison, equivalent program snippets should be used.
# You can plainly measure this for yourself & see I've no
# axe to grind. Now, if *you* want increased complexity in
# order to simply win an argument Jens, well, I guess that's
# fine, but *I* do not.
I don't want increased complexity. My .profile works without case
folding on any Linux I care to have a $HOME. It was you who suggested we
might need to deal with variants on the capitalization of Linux and I
offered my $1/50. I'm not angry, btw, and if I came across as angry ask
for forgiveness.
[...]
# Dunno what else to say...
If *physical* entropy is a concern, don't fork tr(1) when you can easily
solve the task within the shell. It's a question of a million CPU cycles
for a pipe/fork versus a few hundred for a handful of comparisons. You
don't go buying a sugar cube with a lowboy, do you? :-)
I realize that people's sense of aesthetics or readabilty is sometimes
different from mine and makes them pick different solutions. That's
totally fine.
in <p4de4v$aof$1...@news.albasani.net>:
...
# In fact, we can measure[i] the amount of entropy[ii]
# of your string vs. my string (pre-globbing of course,
# which if expanded, only *worsens* the problem):
#
#
# Jens '(*[Ll][Ii][Nn][Uu][Xx]*) PROFILE_OS': 4.2373
#
# Mike '*linux*PROFILE_OS': 3.85217
Where is the entropy for the tr A-Z conversion? For a meaningful
comparison, equivalent program snippets should be used.
# You can plainly measure this for yourself & see I've no
# axe to grind. Now, if *you* want increased complexity in
# order to simply win an argument Jens, well, I guess that's
# fine, but *I* do not.
I don't want increased complexity. My .profile works without case
folding on any Linux I care to have a $HOME. It was you who suggested we
might need to deal with variants on the capitalization of Linux and I
offered my $1/50. I'm not angry, btw, and if I came across as angry ask
for forgiveness.
[...]
# Dunno what else to say...
If *physical* entropy is a concern, don't fork tr(1) when you can easily
solve the task within the shell. It's a question of a million CPU cycles
for a pipe/fork versus a few hundred for a handful of comparisons. You
don't go buying a sugar cube with a lowboy, do you? :-)
I realize that people's sense of aesthetics or readabilty is sometimes
different from mine and makes them pick different solutions. That's
totally fine.
Mike Sanders
Jan 25, 2018, 5:10:38 PM1/25/18
to
Jens Schweikhardt <use...@schweikhardt.net> wrote:
> Where is the entropy for the tr A-Z conversion? For a meaningful
> comparison, equivalent program snippets should be used.
Entropy is not a measure of time Jens. Obviously '|', 'tr',
> Where is the entropy for the tr A-Z conversion? For a meaningful
> comparison, equivalent program snippets should be used.
as well as '$()', incur a penalty (& I accept that & said
as much), I'm referring to an increase in cognitive load
that's unwanted when attempting to help another understand.
I seek to disambiguate, that's how to best help others,
not by eating the young of C.U.S.
You are attempting (flippant remarks notwithstanding)
to critique an abstraction that some might not understand
in depth. Instead, I seek to offer helpful advice to another
who *asked for help* in a manner that well, actually helps.
Maybe its funny to you, I can't help that.
> You don't go buying a sugar cube with a lowboy, do you? :-)
Janis Papanagnou
Jan 25, 2018, 5:37:13 PM1/25/18
to
On 25.01.2018 22:15, Jens Schweikhardt wrote:
[...]
> [...], don't fork tr(1) when you can easily
Of course.
Depending on the used shell we can have both, no external process, no IPC,
and still readable, as (for example) in Ksh with a variable declaration
typeset -l lc=MixedCaseWord
case $lc in
...
Janis
[...]
> [...], don't fork tr(1) when you can easily
> solve the task within the shell. It's a question of a million CPU cycles
> for a pipe/fork versus a few hundred for a handful of comparisons. [...]
Of course.
Depending on the used shell we can have both, no external process, no IPC,
and still readable, as (for example) in Ksh with a variable declaration
typeset -l lc=MixedCaseWord
case $lc in
...
Janis
Janis Papanagnou
Jan 25, 2018, 5:49:16 PM1/25/18
to
On 25.01.2018 23:10, Mike Sanders wrote:
> Jens Schweikhardt <use...@schweikhardt.net> wrote:
>
>> Where is the entropy for the tr A-Z conversion? For a meaningful
>> comparison, equivalent program snippets should be used.
>
> Entropy is not a measure of time Jens. Obviously '|', 'tr',
> as well as '$()', incur a penalty (& I accept that & said
> as much), I'm referring to an increase in cognitive load
> that's unwanted when attempting to help another understand.
If that is really a concern for you - which I think is basically
> Jens Schweikhardt <use...@schweikhardt.net> wrote:
>
>> Where is the entropy for the tr A-Z conversion? For a meaningful
>> comparison, equivalent program snippets should be used.
>
> Entropy is not a measure of time Jens. Obviously '|', 'tr',
> as well as '$()', incur a penalty (& I accept that & said
> as much), I'm referring to an increase in cognitive load
> that's unwanted when attempting to help another understand.
a Good Thing! - then I suggest to start with your own code, e.g.
the one posted initially in this thread, and remove all those
unnecessary '\' that will only confuse and mislead the "young of
C.U.S." you are referring to below. But, frankly, meanwhile I've
seen a lot of code from you that qualifies for a Congnitive Load
Award so that I have my doubts.
> I seek to disambiguate, that's how to best help others,
> not by eating the young of C.U.S.
> [...]
Chris Elvidge
Jan 25, 2018, 6:03:17 PM1/25/18
to
$ UN=$(uname -s); echo ${UN,,}
cygwin_nt-10.0
$ echo ${OSTYPE,,}
linux-gnu
--
Chris Elvidge, England
Mike Sanders
Jan 25, 2018, 6:19:20 PM1/25/18
to
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> [...]
She smells blood.
I'm trying to help for another that asked for...
You know what, not this time Janis, have wrestled
with you enough - kf'd (congrats you're the 1st).
OP seeking help - look me up, we'll build something =)
> [...]
She smells blood.
I'm trying to help for another that asked for...
You know what, not this time Janis, have wrestled
with you enough - kf'd (congrats you're the 1st).
OP seeking help - look me up, we'll build something =)
Mike Sanders
Jan 25, 2018, 6:29:14 PM1/25/18
to
Chris Elvidge <ch...@mshome.net> wrote:
> In bash 4 eg:
>
> $ UN=$(uname -s); echo ${UN,,}
> cygwin_nt-10.0
>
> $ echo ${OSTYPE,,}
> linux-gnu
Hmmm... well, scratch that idea no?
> In bash 4 eg:
>
> $ UN=$(uname -s); echo ${UN,,}
> cygwin_nt-10.0
>
> $ echo ${OSTYPE,,}
> linux-gnu
Many thanks Chris, appreciate the heads up.
Kaz Kylheku
Jan 25, 2018, 6:37:45 PM1/25/18
to
On 2018-01-25, Mike Sanders <mi...@porkchop.bsd> wrote:
> Jens Schweikhardt <use...@schweikhardt.net> wrote:
>
>> If the cost is a useless pipe and fork to tr(1), that's unacceptable.
>
> For you perhaps. For me? Not at all & I'll use it as is.
>
>> For one thing, FreeBSD has always and will always be spelled/spelt that way.
>> I know this because me and my colleagues are taking care of it.
>
> Umm, I'm not sure, but are you're missing the point purposely?
>
> The margin of error increases with the complexity of the string...
For values of "string" being "your code".
> Jens Schweikhardt <use...@schweikhardt.net> wrote:
>
>> If the cost is a useless pipe and fork to tr(1), that's unacceptable.
>
> For you perhaps. For me? Not at all & I'll use it as is.
>
>> For one thing, FreeBSD has always and will always be spelled/spelt that way.
>> I know this because me and my colleagues are taking care of it.
>
> Umm, I'm not sure, but are you're missing the point purposely?
>
> The margin of error increases with the complexity of the string...
> ...*for the person writing the script*
>
> The 'tr' is there to help the script writer only, who may not
> know the correct output because they don't have access to said
> OS yet still wishes to distribute their script for that platform.
that's up to whoever receives the script.
The right thing is to handle only the cases that you are able to
test, and let others go to the "catch all" bucket where the user
is warned that this is an untested configuration.
> But now that you mention it, I sort of did feel it would make
> a great conspiracy...
>
>> For your random Linux distro du jour you use
>>
>> case $uname in
>> (*[Ll][Ii][Nn][Uu][Xx]*) PROFILE_OS=Linux;;
>> esac
>
> But you've offered a terrible alternative in your anger,
> at that 'new guy' there's no sense in it. Its unnecessary
> *word salad*.
cases, just in the chaotic Linux case.
The original doesn't have the * on the left, by the way,
so it may be failing to match on "ucLinux", by the way.
(But if you don't have a ucLinux system, it would be a mistake
to try to handle it anyway.)
Kaz Kylheku
Jan 25, 2018, 6:43:39 PM1/25/18
to
On 2018-01-25, Jens Schweikhardt <use...@schweikhardt.net> wrote:
> Mike Sanders <mi...@porkchop.bsd> wrote
> in <p4de4v$aof$1...@news.albasani.net>:
> ...
> # In fact, we can measure[i] the amount of entropy[ii]
> # of your string vs. my string (pre-globbing of course,
> # which if expanded, only *worsens* the problem):
> #
> #
> # Jens '(*[Ll][Ii][Nn][Uu][Xx]*) PROFILE_OS': 4.2373
> #
> # Mike '*linux*PROFILE_OS': 3.85217
>
> Where is the entropy for the tr A-Z conversion? For a meaningful
> comparison, equivalent program snippets should be used.
>
> # You can plainly measure this for yourself & see I've no
> # axe to grind. Now, if *you* want increased complexity in
> # order to simply win an argument Jens, well, I guess that's
> # fine, but *I* do not.
>
> I don't want increased complexity. My .profile works without case
> folding on any Linux I care to have a $HOME. It was you who suggested we
> might need to deal with variants on the capitalization of Linux and I
> offered my $1/50. I'm not angry, btw, and if I came across as angry ask
> for forgiveness.
We should only deal with those variants if we actually have access to
> in <p4de4v$aof$1...@news.albasani.net>:
> ...
> # In fact, we can measure[i] the amount of entropy[ii]
> # of your string vs. my string (pre-globbing of course,
> # which if expanded, only *worsens* the problem):
> #
> #
> # Jens '(*[Ll][Ii][Nn][Uu][Xx]*) PROFILE_OS': 4.2373
> #
> # Mike '*linux*PROFILE_OS': 3.85217
>
> Where is the entropy for the tr A-Z conversion? For a meaningful
> comparison, equivalent program snippets should be used.
>
> # You can plainly measure this for yourself & see I've no
> # axe to grind. Now, if *you* want increased complexity in
> # order to simply win an argument Jens, well, I guess that's
> # fine, but *I* do not.
>
> I don't want increased complexity. My .profile works without case
> folding on any Linux I care to have a $HOME. It was you who suggested we
> might need to deal with variants on the capitalization of Linux and I
> offered my $1/50. I'm not angry, btw, and if I came across as angry ask
> for forgiveness.
them to test on.
If I don't have a test sytem where "uname -s" is LinuxFoo, I'm not going
to try to code for that. I just don't support that.
To support LinuxFoo means that I commit to that as a feature and get
an installation of LinuxFoo to test on.
If downstream users come to me and say "we wanted your shit to run on
LinuxFoo; here are patches", then I may consider merge their patches,
provided they don't break anything and are of seemingly good quality.
At that point, LinuxFoo is still not officially supported and I'm not
testing on it. When I make changes, I will not do anything that
obviously breaks the LinuxFoo patch, but I won't be validating for it,
so those downstream people may have to fix something once again.
Mike Sanders
Jan 25, 2018, 8:56:20 PM1/25/18
to
Yes finally someone has indicated they understand my point.
Now tell me true... is not always said, 'get it running 1st
then optimize'?
> What I'm getting here is mainly "writer only".
Aye.
> So the writer is coding cases that he has no intention of testing;
> that's up to whoever receives the script.
No contesto, but... if that's truly the case then well nigh
any of us here here could comment on it. (how's that for
circular reasoning =)
> The right thing is to handle only the cases that you are able to
> test, and let others go to the "catch all" bucket where the user
> is warned that this is an untested configuration.
Well yes, but we never got that far with him... somehow I feel
that's getting lost in the mix here. I tried to, but it didn't fly.
> The original doesn't have the * on the left, by the way,
> so it may be failing to match on "ucLinux", by the way.
> (But if you don't have a ucLinux system, it would be a mistake
> to try to handle it anyway.)
Sure enough, Kenny nailed that one.
But hey no biggie, its all good Kaz. Earnestly appreciate you
& others stepping up to bat in an attempt to smooth ruffled
feathers. A decidedly good thing.
Now tell me true... is not always said, 'get it running 1st
then optimize'?
> What I'm getting here is mainly "writer only".
> So the writer is coding cases that he has no intention of testing;
> that's up to whoever receives the script.
any of us here here could comment on it. (how's that for
circular reasoning =)
> The right thing is to handle only the cases that you are able to
> test, and let others go to the "catch all" bucket where the user
> is warned that this is an untested configuration.
that's getting lost in the mix here. I tried to, but it didn't fly.
> The original doesn't have the * on the left, by the way,
> so it may be failing to match on "ucLinux", by the way.
> (But if you don't have a ucLinux system, it would be a mistake
> to try to handle it anyway.)
But hey no biggie, its all good Kaz. Earnestly appreciate you
& others stepping up to bat in an attempt to smooth ruffled
feathers. A decidedly good thing.
Mike Sanders
Jan 26, 2018, 7:03:20 AM1/26/18
to
Jens Schweikhardt <use...@schweikhardt.net> wrote:
> You don't go buying a sugar cube with a lowboy, do you? :-)
To be sure... can someone explain to me the meaning of this idiom?
> You don't go buying a sugar cube with a lowboy, do you? :-)
My dialect of English is very colloquial it seems, & comes from the
prairies of North America. If the above not meant to be a quip,
I may have to apologize.
Janis Papanagnou
Jan 26, 2018, 7:17:35 AM1/26/18
to
On 26.01.2018 13:03, Mike Sanders wrote:
> Jens Schweikhardt <use...@schweikhardt.net> wrote:
>
>> You don't go buying a sugar cube with a lowboy, do you? :-)
>
> To be sure... can someone explain to me the meaning of this idiom?
(Interesting; yesterday you replied to that sentence. Now you say
> Jens Schweikhardt <use...@schweikhardt.net> wrote:
>
>> You don't go buying a sugar cube with a lowboy, do you? :-)
>
> To be sure... can someone explain to me the meaning of this idiom?
you don't understand it?)
My interpretation of that is that you would not shoot a fly with
a tank. (Ouch! - I explained it with another made up non-standard
"idiom".)
Janis
Mike Sanders
Jan 26, 2018, 7:45:44 AM1/26/18
to
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 26.01.2018 13:03, Mike Sanders wrote:
>> Jens Schweikhardt <use...@schweikhardt.net> wrote:
>>
>>> You don't go buying a sugar cube with a lowboy, do you? :-)
>>
>> To be sure... can someone explain to me the meaning of this idiom?
>
> (Interesting; yesterday you replied to that sentence. Now you say
> you don't understand it?)
Or misunderstand... here, sugarbaby (yes I know not sugarcube,
> On 26.01.2018 13:03, Mike Sanders wrote:
>> Jens Schweikhardt <use...@schweikhardt.net> wrote:
>>
>>> You don't go buying a sugar cube with a lowboy, do you? :-)
>>
>> To be sure... can someone explain to me the meaning of this idiom?
>
> (Interesting; yesterday you replied to that sentence. Now you say
> you don't understand it?)
but close) & lowboy (a term used much perhaps a generation or two
ago) could be construed to mean a married man who seeks sex with
very young girls, who themselves, expect gifts as well as money.
Ugh - I think I messed up...
Jens if you're reading, please except my apologies.
The misunderstanding is mine.
> My interpretation of that is that you would not shoot a fly with
> a tank. (Ouch! - I explained it with another made up non-standard
> "idiom".)
Mike Sanders
Jan 26, 2018, 8:05:12 AM1/26/18
to
Mike Sanders <mi...@porkchop.bsd> wrote:
> Jens if you're reading, please except my apologies.
'except' == 'accept'
> Jens if you're reading, please except my apologies.
coffee...
Mike Sanders
Jan 26, 2018, 8:18:06 AM1/26/18
to
Allodoxaphobia <knock_you...@example.net> wrote:
> I have a need" in some of my scripts to detect whether it's running on
> linux or FreeBSD.
Jonesy, this is best I can do right now:
<https://busybox.hypermart.net/detect-os.html>
good luck.
> I have a need" in some of my scripts to detect whether it's running on
> linux or FreeBSD.
Jonesy, this is best I can do right now:
<https://busybox.hypermart.net/detect-os.html>
good luck.
Helmut Waitzmann
Jan 26, 2018, 9:13:28 AM1/26/18
to
Kaz Kylheku <217-67...@kylheku.com>:
[An astonishing experiment with an especially mangled ext2 file
system consenting deleted]
But there is an additional difference between pathname expansion
and pattern matching.
With pathname expansion, a leading "." in a component is not
matched by any pattern other than a pattern containing an
explicit "." at the appropriate position, for example:
printf '%s\n' [.].
won't output "..", but
printf '%s\n' .[.]
will do (assuming there is a filename ".." in the current working
directory).
Whereas with pattern matching, it will match:
case .. in
[.].)
printf '%s\n' '[.]. matches ..'
;;
esac
> On 2018-01-24, Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>> The "case" compound command uses pattern matching
>> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
>> rather than pathname expansion.
>>
>> When pattern matching notation is used for pathname expansion, the
>> pattern matching rules are qualified by additional rules
>> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03>)
>> regarding the slash character in a pathname and the period
>> character at the beginning of a filename.
>
> The rules are basically the same, but the glob function applies matching
> to components, not to entire paths.
Yes, it may have been emplemented like that.
>> The "case" compound command uses pattern matching
>> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13>)
>> rather than pathname expansion.
>>
>> When pattern matching notation is used for pathname expansion, the
>> pattern matching rules are qualified by additional rules
>> (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03>)
>> regarding the slash character in a pathname and the period
>> character at the beginning of a filename.
>
> The rules are basically the same, but the glob function applies matching
> to components, not to entire paths.
[An astonishing experiment with an especially mangled ext2 file
system consenting deleted]
But there is an additional difference between pathname expansion
and pattern matching.
With pathname expansion, a leading "." in a component is not
matched by any pattern other than a pattern containing an
explicit "." at the appropriate position, for example:
printf '%s\n' [.].
won't output "..", but
printf '%s\n' .[.]
will do (assuming there is a filename ".." in the current working
directory).
Whereas with pattern matching, it will match:
case .. in
[.].)
printf '%s\n' '[.]. matches ..'
;;
esac
Jim Beard
Jan 26, 2018, 10:21:50 AM1/26/18
to
For others interested in such things, "lowboy" in Texas, Oklahoma, and
nearby locales usually refers to "a gooseneck trailer," suitable for
moving quantities ranging from many kilograms (or hundreds of pounds) up
to a few tons (thousands of kilograms).
Cheers!
jim b.
--
UNIX is not user-unfriendly, it merely expects users to be computer-
friendly.
Jens Schweikhardt
Jan 26, 2018, 1:33:52 PM1/26/18
to
Mike Sanders <mi...@porkchop.bsd> wrote
in <p4f5e4$e90$1...@news.albasani.net>:
# Jens Schweikhardt <use...@schweikhardt.net> wrote:
#
#> You don't go buying a sugar cube with a lowboy, do you? :-)
#
# To be sure... can someone explain to me the meaning of this idiom?
Happy to help: https://en.wikipedia.org/wiki/Lowboy_(trailer)
In short, the big boy's version of a flatbed truck.
Forking to tr to flip exactly one bit in a few characters is
as overkill as shopping for a sugar cube with a lowboy. No one
sane would assume that's efficient or warranted.
I'm not a native speaker and made that one up on-the-fly. I
don't think it's in any way idiomatic, so please don't question
your mastery of English, BE, AE or otherwise :-)
Now if you could explain about that mop water to me...
in <p4f5e4$e90$1...@news.albasani.net>:
# Jens Schweikhardt <use...@schweikhardt.net> wrote:
#
#> You don't go buying a sugar cube with a lowboy, do you? :-)
#
# To be sure... can someone explain to me the meaning of this idiom?
Happy to help: https://en.wikipedia.org/wiki/Lowboy_(trailer)
In short, the big boy's version of a flatbed truck.
Forking to tr to flip exactly one bit in a few characters is
as overkill as shopping for a sugar cube with a lowboy. No one
sane would assume that's efficient or warranted.
I'm not a native speaker and made that one up on-the-fly. I
don't think it's in any way idiomatic, so please don't question
your mastery of English, BE, AE or otherwise :-)
Now if you could explain about that mop water to me...
Mike Sanders
Jan 26, 2018, 6:21:36 PM1/26/18
to
Jens Schweikhardt <use...@schweikhardt.net> wrote:
> Now if you could explain about that mop water to me...
This is a mildly audacious 'comeback'. For instance,
> Now if you could explain about that mop water to me...
if one said to another, 'You are silly', the other might
reply to the first, 'Perhaps, but you are sillier than I'.
In other words, one might feel that 'tr' is an expensive
substitution with respect to efficiency, while another
might feel that globing lessens 'readability'.
Speaking only for myself: efficiency vs. readability
(as one of the two is favored, entropy increases for the other).
Chris Elvidge
Jan 26, 2018, 6:46:18 PM1/26/18
to
http://aty.sdsu.edu/bibliog/latex/debian/bash.html
--
Chris Elvidge, England
Mike Sanders
Jan 26, 2018, 7:20:51 PM1/26/18
to
Chris Elvidge <ch...@mshome.net> wrote:
> As in the title, you might be interested in an actual test.
> http://aty.sdsu.edu/bibliog/latex/debian/bash.html
Thinking to myself...
> As in the title, you might be interested in an actual test.
> http://aty.sdsu.edu/bibliog/latex/debian/bash.html
And how is readability measured? Is the HTML within
the page cited optimized for a machine or a human?
When the page is rendered, the tags themselves are not.
[bold] foo [/bold]
Quite literally an example that while meant to illustrate
efficiency, requires the use of readability to communicate
its message.
Funky dory.
Mike Sanders
Jan 26, 2018, 8:16:01 PM1/26/18
to
Chris Elvidge <ch...@mshome.net> wrote:
> As in the title, you might be interested in an actual test.
> http://aty.sdsu.edu/bibliog/latex/debian/bash.html
btw Chris, I should have ackowledged your
> As in the title, you might be interested in an actual test.
> http://aty.sdsu.edu/bibliog/latex/debian/bash.html
input eariler upthread while showing examples
to Jonesy:
lowered=${string,,}
Hope you'll forgive my oversite. Yes (imo)
even MORE readable (less funky dory) than
'tr' & without the cost of a fork to boot.
Thank you for your input.
Can't yet seem to keep up with all you gurus
here, still finding my way around.
Jens Schweikhardt
Jan 27, 2018, 9:55:33 AM1/27/18
to
Mike Sanders <mi...@porkchop.bsd> wrote
in <p4ggku$32s$1...@news.albasani.net>:
...
# And how is readability measured?
Since code readability is to some extent subjective, by asking a large
set S of test subjects familiar with the code constructs. You present
the test subjects N code samples performing equivalent tasks. You could
give them all N at once, asking to order for readability. Or maybe
present pairs of snippets, asking for the more readable of the two. Do
this with large enough S and N and you could be able to distill some
readability recommendations.
Encoding entropy is probably not as correlated with readability as you
may think. Shorter is not always more readable. This becomes especially
apparent when you look at text files and their compressed versions. I
for one can't read zip files.
in <p4ggku$32s$1...@news.albasani.net>:
...
# And how is readability measured?
Since code readability is to some extent subjective, by asking a large
set S of test subjects familiar with the code constructs. You present
the test subjects N code samples performing equivalent tasks. You could
give them all N at once, asking to order for readability. Or maybe
present pairs of snippets, asking for the more readable of the two. Do
this with large enough S and N and you could be able to distill some
readability recommendations.
Encoding entropy is probably not as correlated with readability as you
may think. Shorter is not always more readable. This becomes especially
apparent when you look at text files and their compressed versions. I
for one can't read zip files.
Mike Sanders
Jan 27, 2018, 11:54:07 AM1/27/18
to
Jens Schweikhardt <use...@schweikhardt.net> wrote:
> Since code readability is to some extent subjective, by asking a large
> set S of test subjects familiar with the code constructs. You present
> the test subjects N code samples performing equivalent tasks. You could
> give them all N at once, asking to order for readability. Or maybe
> present pairs of snippets, asking for the more readable of the two. Do
> this with large enough S and N and you could be able to distill some
> readability recommendations.
>
> Encoding entropy is probably not as correlated with readability as you
> may think. Shorter is not always more readable. This becomes especially
> apparent when you look at text files and their compressed versions. I
> for one can't read zip files.
Hi Jens. Yes, very thoughtful examples indeed. I think you're correct,
> Since code readability is to some extent subjective, by asking a large
> set S of test subjects familiar with the code constructs. You present
> the test subjects N code samples performing equivalent tasks. You could
> give them all N at once, asking to order for readability. Or maybe
> present pairs of snippets, asking for the more readable of the two. Do
> this with large enough S and N and you could be able to distill some
> readability recommendations.
>
> Encoding entropy is probably not as correlated with readability as you
> may think. Shorter is not always more readable. This becomes especially
> apparent when you look at text files and their compressed versions. I
> for one can't read zip files.
shorter does not, shorter could not, always equal greator readability.
Exploring this thought experiment deeper still...
Consider 'BSD': Only knowing in advance that 'BSD' is a mnemonic for
'Berkeley Software Distribution', do those three characters unfold
with meaning. I submit another example using the same modality,
a shell alias...
rtfm() { $@ --help || man $@ || lynx "http://www.google.com/search?q=$@"; }
Now, complexity is wrapped behind a familiar label (like 'tr' for instance).
Which could, if you & I are simply enjoying a code-snack (thinking aloud
& sharing speculation that is), be thought as a shortcut, where deeper
abstractions are embedded within the meme itseslf.
I know I ramble on but, its a fascinating subject isn't it? =)
0 new messages