Google 網路論壇不再支援新的 Usenet 貼文或訂閱項目,但過往內容仍可供查看。

Wrote a bash script to create and add a swapfile

瀏覽次數:20 次
跳到第一則未讀訊息

Cecil Westerhof

未讀,
2022年8月16日 上午8:44:072022/8/16
收件者:
For people who know Bash, but like to learn write (better) scripts I
wrote an article about a script I wrote to create and add a swapfile:
https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof

You can get the script here:
https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwapFile.sh

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Ben Bacarisse

未讀,
2022年8月16日 上午9:02:182022/8/16
收件者:
Cecil Westerhof <Ce...@decebal.nl> writes:

> For people who know Bash, but like to learn write (better) scripts I
> wrote an article about a script I wrote to create and add a swapfile:
> https://...

Why post a link? We discuss shell programming here, not there! Post
the content here.

Posting links and no content is what spammers do and I'm sure you don't
want to be taken for a spammer.

--
Ben.

Kenny McCormack

未讀,
2022年8月16日 上午10:17:212022/8/16
收件者:
In article <87mtc45...@bsb.me.uk>,
Let me first say that I 100% agree with you in principle. That in the
model of classic Usenet, sure, OP could have just posted his script in the
item. However, let me play devil's advocate for the rest of this post:

1) We live in a "clicks equals money" world, and it is quite possible that
OP was looking to make a little cash from having you follow his links.
Given that we live in a world where the elites are crushing the middle
class, and everybody is encouraged to have a "side hustle" or two, I can't
say this is necessarily a bad thing (on OP's part).

2) I'm not sure that OP is interested in the usual "human compiler"
treatment that we usually deal in here on Usenet. That is, where eager
folks like you and me go through his script line by line, like a compiler
would, and make derogatory comments where we can. Instead, I think he was
just putting it out there as something you may (or may not) enjoy reading.
I really didn't get the impression that he wanted or was seeking any human
compilers.

Note, BTW, that I did go and read his post (on linked in) and if I *WAS* so
inclined, I could make some (in fact, quite a few) human compiler comments,
but I do not intend on doing so.

--
"The most unsettling aspect of my atheism for Christians is
when they realize that their Bible has no power to make me
wince. They are used to using it like a cattle prod to get
people to cower into compliance." - Author unknown

Auric__

未讀,
2022年8月16日 上午11:26:382022/8/16
收件者:
Cecil Westerhof wrote:

> For people who know Bash, but like to learn write (better) scripts I
> wrote an article about a script I wrote to create and add a swapfile:
> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
>
> You can get the script here:
> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwap
> File.sh

In the future, please don't multi-post. Crosspost instead. (Also found in
alt.os.linux.)

--
Time and space are illusions.

Aragorn

未讀,
2022年8月16日 下午1:37:252022/8/16
收件者:
On 16.08.2022 at 14:17, Kenny McCormack scribbled:

> In article <87mtc45...@bsb.me.uk>,
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> >Cecil Westerhof <Ce...@decebal.nl> writes:
> >
> >> For people who know Bash, but like to learn write (better) scripts
> >> I wrote an article about a script I wrote to create and add a
> >> swapfile: https://...
> >
> >Why post a link? We discuss shell programming here, not there! Post
> >the content here.
> >
> >Posting links and no content is what spammers do and I'm sure you
> >don't want to be taken for a spammer.
>
> Let me first say that I 100% agree with you in principle. That in the
> model of classic Usenet, sure, OP could have just posted his script
> in the item.

So far, so good, and I agree with you on that.

> However, let me play devil's advocate for the rest of this post:
>
> 1) We live in a "clicks equals money" world, and it is quite possible
> that OP was looking to make a little cash from having you follow his
> links. Given that we live in a world where the elites are crushing
> the middle class, and everybody is encouraged to have a "side hustle"
> or two, I can't say this is necessarily a bad thing (on OP's part).

I have interacted with Cecil in person off of Usenet several years ago
regarding a presentation he was creating on account of systemd — he
himself may not remember that anymore, but I happen to have an eidetic
memory.

Cecil is not the kind of person you are describing above. He is
someone who's eager to contribute to the FLOSS community, he
absolutely loves scripting in GNU bash, and he takes pride in his work.

His thread was also posted to at least one other newsgroup I'm
monitoring — perhaps he forgot to cross-post and so ended up
multi-posting — and it was intended as a mere announcement.

> 2) I'm not sure that OP is interested in the usual "human compiler"
> treatment that we usually deal in here on Usenet. That is, where
> eager folks like you and me go through his script line by line, like
> a compiler would, and make derogatory comments where we can.
> Instead, I think he was just putting it out there as something you
> may (or may not) enjoy reading. I really didn't get the impression
> that he wanted or was seeking any human compilers.

As I said, it was a mere announcement.

> Note, BTW, that I did go and read his post (on linked in) and if I
> *WAS* so inclined, I could make some (in fact, quite a few) human
> compiler comments, but I do not intend on doing so.

From my prior interactions with Cecil, I know that he always welcomes
all constructive commentary. But he wasn't fishing for it, and knowing
him, his code is probably sufficiently good already, even if perhaps
not perfect.

--
With respect,
= Aragorn =

Cecil Westerhof

未讀,
2022年8月16日 下午1:44:072022/8/16
收件者:
I would not know how, but that is not a problem: that is easy to find
out I think.

But I often have seen rants about cross-posting. So I was wondering
what the consensus is about this in the newsgroup.

Cecil Westerhof

未讀,
2022年8月16日 下午1:44:072022/8/16
收件者:
Cecil Westerhof <Ce...@decebal.nl> writes:

> For people who know Bash, but like to learn write (better) scripts I
> wrote an article about a script I wrote to create and add a swapfile:
> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
>
> You can get the script here:
> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwapFile.sh

The script my post explains.



#!/usr/bin/env bash

set -o errexit
set -o nounset



function getFreeGB {
df -BG $(dirname $1) | \
tail -n 1 | \
awk '{print substr($4, 1, length($4) - 1)}'
}

function giveError {
echo $1
exit 1
}


declare -r _scriptName=$(basename ${0})
if [[ $(id --user) -ne 0 ]] ; then
giveError "${_scriptName} should be run as root"
fi
if [[ $# -ne 2 ]] ; then
giveError "ERROR: ${_scriptName} SWAPFILE GB"
fi
declare -r _swapFile=$1
declare -ir _gb=$2

if [[ -e ${_swapFile} ]] ; then
giveError "${_swapFile} already exists"
fi
declare -ir _gbFree=$(getFreeGB ${_swapFile})
# Make sure swapfile is less as a quarter of free space
if [[ ${_gbFree} -le $(($_gb * 4)) ]] ; then
giveError "Not enough space for swap file ($_gb, ${_gbFree})"
fi
echo Current Swap:
swapon
echo
date "+%T: Creating ${_swapFile}"
dd if=/dev/zero of=${_swapFile} bs=1024 count=$(($_gb * 1024 ** 2))
echo
chmod 600 ${_swapFile}
mkswap ${_swapFile}
swapon ${_swapFile}
echo New Swap:
swapon

Cecil Westerhof

未讀,
2022年8月16日 下午1:44:072022/8/16
收件者:
gaz...@shell.xmission.com (Kenny McCormack) writes:

> In article <87mtc45...@bsb.me.uk>,
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>Cecil Westerhof <Ce...@decebal.nl> writes:
>>
>>> For people who know Bash, but like to learn write (better) scripts I
>>> wrote an article about a script I wrote to create and add a swapfile:
>>> https://...
>>
>>Why post a link? We discuss shell programming here, not there! Post
>>the content here.
>>
>>Posting links and no content is what spammers do and I'm sure you don't
>>want to be taken for a spammer.
>
> Let me first say that I 100% agree with you in principle. That in the
> model of classic Usenet, sure, OP could have just posted his script in the
> item. However, let me play devil's advocate for the rest of this post:
>
> 1) We live in a "clicks equals money" world, and it is quite possible that
> OP was looking to make a little cash from having you follow his links.
> Given that we live in a world where the elites are crushing the middle
> class, and everybody is encouraged to have a "side hustle" or two, I can't
> say this is necessarily a bad thing (on OP's part).

No it is not about clicks. ;-)
I created a bash group on LinkedIn and there was a question about how
to learn to program in bash. So I wrote a script and an article
explaining the script with hopefully interesting tips for people how
to create their own scripts.

I just thought/hoped it could be interesting for people using this
newsgroup.


> 2) I'm not sure that OP is interested in the usual "human compiler"
> treatment that we usually deal in here on Usenet. That is, where eager
> folks like you and me go through his script line by line, like a compiler
> would, and make derogatory comments where we can. Instead, I think he was
> just putting it out there as something you may (or may not) enjoy reading.
> I really didn't get the impression that he wanted or was seeking any human
> compilers.

That is right.


> Note, BTW, that I did go and read his post (on linked in) and if I *WAS* so
> inclined, I could make some (in fact, quite a few) human compiler comments,
> but I do not intend on doing so.

I do not mind getting them. :-D
Put I think it would be best at the post itself, because then it will
reach the most people.

Aragorn

未讀,
2022年8月16日 下午1:58:432022/8/16
收件者:
On 16.08.2022 at 19:33, Cecil Westerhof scribbled:

> "Auric__" <not.m...@email.address> writes:
>
> > Cecil Westerhof wrote:
> >
> >> For people who know Bash, but like to learn write (better) scripts
> >> I wrote an article about a script I wrote to create and add a
> >> swapfile:
> >> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
> >>
> >> You can get the script here:
> >> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwap
> >> File.sh
> >
> > In the future, please don't multi-post. Crosspost instead. (Also
> > found in alt.os.linux.)
>
> I would not know how, but that is not a problem: that is easy to find
> out I think.

You simply put multiple newsgroups in the "To:" or "Newsgroups:" field
of your newsreader's editor — I'm not familiar with Gnus, sorry — with
the names separated by a comma.

A good newsreader will recognize cross-posted threads and will not open
them as a new thread when you select a different newsgroup for reading
and said group was included in the cross-post list — it will however
display the followups if they themselves were not cross-posted.

If you multi-post on the other hand, then the newsreader does not see
any correlation and will regard it as just another new and standalone
thread. And of course, people won't be able to reply to your thread
just once and have their reply propagated to the same other newsgroups
where the thread is posted all in one go.

Cecil Westerhof

未讀,
2022年8月16日 下午2:44:072022/8/16
收件者:
Well, if I do not see people starkly disagreeing I will start
cross-posting.

Cecil Westerhof

未讀,
2022年8月16日 下午2:44:072022/8/16
收件者:
Aragorn <thor...@telenet.be> writes:

> I have interacted with Cecil in person off of Usenet several years ago
> regarding a presentation he was creating on account of systemd — he
> himself may not remember that anymore, but I happen to have an eidetic
> memory.

I do not remember this instance, but I know that most of the time I
appreciate your posts.


> Cecil is not the kind of person you are describing above. He is
> someone who's eager to contribute to the FLOSS community, he
> absolutely loves scripting in GNU bash, and he takes pride in his work.

Thank you for the compliment.


> From my prior interactions with Cecil, I know that he always welcomes
> all constructive commentary. But he wasn't fishing for it, and
> knowing

Yes: I always like to learn.


> him, his code is probably sufficiently good already, even if perhaps
> not perfect.

You make me blush.

David W. Hodgins

未讀,
2022年8月16日 下午5:02:552022/8/16
收件者:
On Tue, 16 Aug 2022 14:35:35 -0400, Cecil Westerhof <Ce...@decebal.nl> wrote:
> Well, if I do not see people starkly disagreeing I will start
> cross-posting.

Use of cross-posting is ok as long as there are not too many groups, and it's
on topic for all included groups.

Try to limit it to no more than 3 groups.

Regards, Dave Hodgins

Helmut Waitzmann

未讀,
2022年8月16日 下午5:20:572022/8/16
收件者:
Cecil Westerhof <Ce...@decebal.nl>:
>
>Well, if I do not see people starkly disagreeing I will start
>cross-posting.

Yes, make it so.  You might read the article


Subject: FAQ: Current Usenet spam thresholds and guidelines
Summary: This posting contains the current Spam definitions, thresholds,
and guidelines, as used by most major spam cancellers and news
administrators.
From: tski...@killfile.org (Tim Skirvin)
Reply-To: tski...@killfile.org
Newsgroups: news.admin.net-abuse.usenet, news.admin.net-abuse.misc,
news.answers
Followup-To: news.admin.net-abuse.usenet
Date: Sun, 14 Aug 2022 00:02:02 +0000
Expires: Sun, 25 Sep 2022 00:02:02 GMT
Message-ID: <spam-faq.20220814000202$1c...@news.killfile.org>


(which itself is a crossposting) regarding excessive crossposting
and excessive multi‐posting, though, to see what a well‐behaved
crossposting might be.

Janis Papanagnou

未讀,
2022年8月17日 清晨6:32:262022/8/17
收件者:
On 16.08.2022 19:37, Cecil Westerhof wrote:
> Cecil Westerhof <Ce...@decebal.nl> writes:
>
>> For people who know Bash, but like to learn write (better) scripts I
>> wrote an article about a script I wrote to create and add a swapfile:
>> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
>>
>> You can get the script here:
>> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwapFile.sh
>
> The script my post explains.

Since you spread (thus multiply) knowledge about scripting I'd like to
give a few comments...

> #!/usr/bin/env bash
>
> set -o errexit
> set -o nounset
>
>
>
> function getFreeGB {
> df -BG $(dirname $1) | \
> tail -n 1 | \
> awk '{print substr($4, 1, length($4) - 1)}'
> }

In scripting the backslashes as a line continuation are a bad concept
since you don't see whether there's whitespace characters (other than
the newline character) there. Specifically a final pipe symbol doesn't
need any explicit textual line continuation so it can be anyway just
omitted.

Since you want only the last line of the df output you can let awk do
that job; at the end of processing the last processed input line is
still available in the END section, a simple change

df -BG $(dirname $1) |
awk 'END {print substr($4, 1, length($4) - 1)}'

and since you want to strip just the numerical part from the field $4
you can simplify that substr/langth by doing numeric "type casting"

df -BG $(dirname $1) |
awk 'END {print 0+$4}'


Below I am wondering why you are not consistently using braces when
expanding variables; we see ${0} and $2, and we see ${_gbFree} and
$_gb. I think this is confusing for folks that are learning shell -
as I understood that this was the (or one) intention of your post.
Whatever you prefer, but mixing is not a good thing as a paragon.

Since you're using a modern shell like bash (and obviously don't
restrict to POSIX) I wonder why you don't use arithmetic expressions.
Instead of

if [[ ${_gbFree} -le $(($_gb * 4)) ]]

there's the much clearer

if (( _gbFree <= _gb * 4 ))


Finally, and especially if a variable is named "File", I'd quote the
variable expansions ("${_swapFile}"), as a paragon for the learning
folks, but also as an actual safety measure (since it's initialized
by the caller through $1, which can contain white-space characters).

Note: I haven't read the article behind your posted link, and I also
haven't inspected every line of your code; my comments are just from
a few quite obvious observations in the posted shell source code.

Janis

Ed Morton

未讀,
2022年8月17日 上午10:24:102022/8/17
收件者:
On 8/16/2022 12:30 PM, Cecil Westerhof wrote:
<snip>
> I created a bash group on LinkedIn and there was a question about how
> to learn to program in bash. So I wrote a script and an article
> explaining the script with hopefully interesting tips for people how
> to create their own scripts.
>
> I just thought/hoped it could be interesting for people using this
> newsgroup.

Then I wish you had posted your script and article here and pointed
people from LinkedIn here instead of doing it the other way around.
There's already far too many places for people to ask and look up
answers to shell questions (this NG, other usenet groups, stackexchange,
stackoverflow, unix.com, etc., etc.), the last thing the larger
community of shell users needs is yet another location (LinkedIn!) to
have to look for answers in.

Ed.


Ed Morton

未讀,
2022年8月17日 上午10:35:052022/8/17
收件者:
On 8/16/2022 12:37 PM, Cecil Westerhof wrote:
> Cecil Westerhof <Ce...@decebal.nl> writes:
>
>> For people who know Bash, but like to learn write (better) scripts I
>> wrote an article about a script I wrote to create and add a swapfile:
>> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
>>
>> You can get the script here:
>> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwapFile.sh
>
> The script my post explains.

You should copy/paste your script into http://shellcheck.net and fix the
issues it tells you about (e.g. the missing quotes in several places).

A few additional things I noticed:

You're using `{...}` unnecessarily everywhere, I think maybe you're
mistaking what curly brackets do (just separate a variable from
concatenated text) vs what double quotes do (protect your variable from
globbing, word splitting, and filename expansion).

The use of `function foo {` is non-portable, use `foo() {` instead.

When printing error messages (e.g. inside "giveError()") add `>&2` so
the message goes to stderr instead of stdout.

Ed.

Kenny McCormack

未讀,
2022年8月17日 上午10:39:052022/8/17
收件者:
In article <tdiuaj$f9b7$1...@dont-email.me>,
Ed Morton <morto...@gmail.com> wrote:
>On 8/16/2022 12:37 PM, Cecil Westerhof wrote:
>> Cecil Westerhof <Ce...@decebal.nl> writes:
>>
>>> For people who know Bash, but like to learn write (better) scripts I
>>> wrote an article about a script I wrote to create and add a swapfile:
>>> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
>>>
>>> You can get the script here:
>>> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwapFile.sh
>>
>> The script my post explains.
>
>You should copy/paste your script into http://shellcheck.net and fix the
>issues it tells you about (e.g. the missing quotes in several places).

Here comes the human compiler.

As predicted.

--
Which of these is the crazier bit of right wing lunacy?
1) We've just had another mass shooting; now is not the time to be talking about gun control.

2) We've just had a massive hurricane; now is not the time to be talking about climate change.

Ed Morton

未讀,
2022年8月17日 上午10:40:262022/8/17
收件者:
On 8/17/2022 5:32 AM, Janis Papanagnou wrote:
> On 16.08.2022 19:37, Cecil Westerhof wrote:

<snip>

> Since you want only the last line of the df output you can let awk do
> that job; at the end of processing the last processed input line is
> still available in the END section, a simple change
>
> df -BG $(dirname $1) |
> awk 'END {print substr($4, 1, length($4) - 1)}'

At the end of processing the last processed input line is not guaranteed
to still available in the END section.

The value of $4 or any other field or $0 is undefined (by POSIX) in the
END section. In some awk variants it will be the $4 from the last record
read as you want, but in others it'll be null, and in others still it
could be anything else. To do what you show above portably in all awks
would be:

awk '{p=$4} END{print substr(p, 1, length(p) - 1)}'

Regards,

Ed.

Aragorn

未讀,
2022年8月17日 上午11:01:412022/8/17
收件者:
On 17.08.2022 at 09:34, Ed Morton scribbled:

> You're using `{...}` unnecessarily everywhere, I think maybe you're
> mistaking what curly brackets do (just separate a variable from
> concatenated text) vs what double quotes do (protect your variable
> from globbing, word splitting, and filename expansion).

There's nothing wrong with being consistent in using accolades for all
variable names.

For one, it makes shell scripts easier to understand for novices than
the reserved use of accolades for when the variable name is being
concatenated with another string only wile not using the accolades
elsewhere. And in the environment where I have to explain things or
solve problems by way of shell commands and scripts, virtually 95% of
the audience is an absolute novice.

For that reason alone, I myself also consistently use the accolade
notation inside scripts intended to be saved on disk, although I'll
admit that I commonly omit them in one-liners, and especially so on my
own system here.

> The use of `function foo {` is non-portable, use `foo() {` instead.

I agree with that, and I myself always write my scripts in the most
portable way, but the OP has very clearly indicated that it is a bash
script, and that it's specifically intended for use in GNU/Linux, where
GNU bash is still the main shell.

I don't even know how many other UNIX variants would support the
use of swap files instead of a dedicated swap partition. macOS and
Solaris/OpenIndiana, yes — macOS uses them by default, even. The current
batch of BSDs, maybe. But I suspect that HP/UX, AIX and whatever OSF/1
installations might still remain in use today do not.

Auric__

未讀,
2022年8月17日 上午11:40:382022/8/17
收件者:
David W. Hodgins wrote:

> On Tue, 16 Aug 2022 14:35:35 -0400, Cecil Westerhof <Ce...@decebal.nl>
> wrote:
>> Well, if I do not see people starkly disagreeing I will start
>> cross-posting.
>
> Use of cross-posting is ok as long as there are not too many groups, and
> it's on topic for all included groups.

Agreed. And crossposting is *always* better than multi-posting. Multi-posting
is the spammer's tactic; crossposting invites discussion between people who
may not normally interact.

> Try to limit it to no more than 3 groups.

A few more *might* be acceptable if there's good reason for posting in 4 or 5
or whatever, but past a certain point, you need to ask yourself, "Do I
*really* need to post this in 12 groups?"

--
When I die, I want the people I did group projects with to
lower me into the ground so they can let me down one last time.

Ed Morton

未讀,
2022年8月17日 上午11:41:352022/8/17
收件者:
On 8/17/2022 10:01 AM, Aragorn wrote:
> On 17.08.2022 at 09:34, Ed Morton scribbled:
>
>> You're using `{...}` unnecessarily everywhere, I think maybe you're
>> mistaking what curly brackets do (just separate a variable from
>> concatenated text) vs what double quotes do (protect your variable
>> from globbing, word splitting, and filename expansion).
>
> There's nothing wrong with being consistent in using accolades for all
> variable names.

I wouldn't have mentioned the curly brackets on their own as they're
harmless but I pointed out them out as I think the OP may be using them
thinking they will do what double quotes actually do as far as
protecting the variable.

Ed.

Cecil Westerhof

未讀,
2022年8月17日 上午11:44:072022/8/17
收件者:
Janis Papanagnou <janis_pa...@hotmail.com> writes:

> On 16.08.2022 19:37, Cecil Westerhof wrote:
>> Cecil Westerhof <Ce...@decebal.nl> writes:
>>
>>> For people who know Bash, but like to learn write (better) scripts I
>>> wrote an article about a script I wrote to create and add a swapfile:
>>> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
>>>
>>> You can get the script here:
>>> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwapFile.sh
>>
>> The script my post explains.
>
> Since you spread (thus multiply) knowledge about scripting I'd like to
> give a few comments...

Thanks I already extensively rewrote the script based on feedback. You
bring forth some other good points.


>> function getFreeGB {
>> df -BG $(dirname $1) | \
>> tail -n 1 | \
>> awk '{print substr($4, 1, length($4) - 1)}'
>> }
>
> In scripting the backslashes as a line continuation are a bad concept
> since you don't see whether there's whitespace characters (other than
> the newline character) there. Specifically a final pipe symbol doesn't
> need any explicit textual line continuation so it can be anyway just
> omitted.

I know that you have to be careful that the backslash is the last
character on the line, but I find it important that lines (if
possible) are less as 80 characters.
I did not know that the final pipe symbol does not need an explicit
context. That is going to make my live easier.


> Since you want only the last line of the df output you can let awk do
> that job; at the end of processing the last processed input line is
> still available in the END section, a simple change

I was wondering about that, wanted to verify it, but 'needed' to
publish something fast.


> df -BG $(dirname $1) |
> awk 'END {print substr($4, 1, length($4) - 1)}'
>
> and since you want to strip just the numerical part from the field $4
> you can simplify that substr/langth by doing numeric "type casting"
>
> df -BG $(dirname $1) |
> awk 'END {print 0+$4}'

That is also an huge improvement.

I had already added that the partition should be on /dev and that a
warning is given when the file system is btrfs.
So the function has become:
function getFreeGB {
fields="$(df -BG -T $(dirname $1) | awk 'END { print $1, $2, 0 + $5 }')"
read dev fs gb <<< "${fields}"
# Check $dev starts with /dev/
if [[ ! $dev =~ ^/dev/.* ]]; then
giveError "File system is not on /dev ($dev)" 5
fi
if [[ $fs == btrfs ]] ; then
echo "This script is not guaranted to work with btrfs" >&2
fi
echo $gb
}


> Below I am wondering why you are not consistently using braces when
> expanding variables; we see ${0} and $2, and we see ${_gbFree} and
> $_gb. I think this is confusing for folks that are learning shell -
> as I understood that this was the (or one) intention of your post.
> Whatever you prefer, but mixing is not a good thing as a paragon.

Oops, that I used ${0} was certainly wrong. :'-(

Let me explain. In the past people where really annoyed by me using
braces. "It is not necessary." But there are some cases where they are
important. That is why I decided that when the length of a name is not
more as 4 characters long I will not use braces and otherwise I will.
But I should explain that.


> Since you're using a modern shell like bash (and obviously don't
> restrict to POSIX)

I am a bit on the fence with that. In a way I like to confirm to
POSIX. But not rigorously. For example I use long options, but
mentions what the corresponding short ones are. Handy for people that
have a POSIX compliant awk.

> I wonder why you don't use arithmetic expressions. Instead of
>
> if [[ ${_gbFree} -le $(($_gb * 4)) ]]
>
> there's the much clearer
>
> if (( _gbFree <= _gb * 4 ))

Correct, implemented.


> Finally, and especially if a variable is named "File", I'd quote the
> variable expansions ("${_swapFile}"), as a paragon for the learning
> folks, but also as an actual safety measure (since it's initialized
> by the caller through $1, which can contain white-space characters).

You are right again. I 'always' say I want to use 'unnecessary'
checks, because I am (hopefully) not the only person that uses my
scripts. But I dropped the ball here. :'-(


> Note: I haven't read the article behind your posted link, and I also
> haven't inspected every line of your code; my comments are just from
> a few quite obvious observations in the posted shell source code.

It is very much appreciated.

Cecil Westerhof

未讀,
2022年8月17日 上午11:59:072022/8/17
收件者:
For me it works, but I should implement something like this then.

Thanks.

Cecil Westerhof

未讀,
2022年8月17日 上午11:59:072022/8/17
收件者:
Ed Morton <morto...@gmail.com> writes:

> On 8/16/2022 12:30 PM, Cecil Westerhof wrote:
> <snip>
>> I created a bash group on LinkedIn and there was a question about how
>> to learn to program in bash. So I wrote a script and an article
>> explaining the script with hopefully interesting tips for people how
>> to create their own scripts.
>> I just thought/hoped it could be interesting for people using this
>> newsgroup.
>
> Then I wish you had posted your script and article here and pointed
> people from LinkedIn here instead of doing it the other way around.

I do not think that will work. I love usenet, but we (users of usenet)
are a dying race. Most people do not even know it exists.

Kenny McCormack

未讀,
2022年8月17日 中午12:05:422022/8/17
收件者:
In article <871qtea...@munus.decebal.nl>,
Cecil Westerhof <Ce...@decebal.nl> wrote:
...
>> awk '{p=$4} END{print substr(p, 1, length(p) - 1)}'
>
>For me it works, but I should implement something like this then.

Or you could just use either mawk or gawk, which are known to work.

I always recommend against using plain old "awk" in a script, b/c you never
know what you are going to get.

Until fairly recently, using plain "awk" under Solaris got you a very old,
essentially non-functional version of AWK.

--
People sleep peaceably in their beds at night only because rough
men stand ready to do violence on their behalf.

George Orwell

Ed Morton

未讀,
2022年8月17日 中午12:09:082022/8/17
收件者:
On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
> Ed Morton <morto...@gmail.com> writes:
>
>> On 8/16/2022 12:30 PM, Cecil Westerhof wrote:
>> <snip>
>>> I created a bash group on LinkedIn and there was a question about how
>>> to learn to program in bash. So I wrote a script and an article
>>> explaining the script with hopefully interesting tips for people how
>>> to create their own scripts.
>>> I just thought/hoped it could be interesting for people using this
>>> newsgroup.
>>
>> Then I wish you had posted your script and article here and pointed
>> people from LinkedIn here instead of doing it the other way around.
>
> I do not think that will work. I love usenet, but we (users of usenet)
> are a dying race. Most people do not even know it exists.
>

Usenet was just one example of an existing forum, if you don't like
usenet pick one of the many other existing forums to post your script
and explanation on. StackExchange and StackOverflow seem to me to be the
most popular these days, but idk, there's lots to choose from. The point
was to not introduce yet another forum for people to have to search for
answers.

Ed.

Cecil Westerhof

未讀,
2022年8月17日 中午12:14:062022/8/17
收件者:
Ed Morton <morto...@gmail.com> writes:

> On 8/16/2022 12:37 PM, Cecil Westerhof wrote:
>> Cecil Westerhof <Ce...@decebal.nl> writes:
>>
>>> For people who know Bash, but like to learn write (better) scripts I
>>> wrote an article about a script I wrote to create and add a swapfile:
>>> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
>>>
>>> You can get the script here:
>>> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwapFile.sh
>> The script my post explains.
>
> You should copy/paste your script into http://shellcheck.net and fix the
> issues it tells you about (e.g. the missing quotes in several places).

I did not know that. I am going to try this out.


> A few additional things I noticed:
>
> You're using `{...}` unnecessarily everywhere, I think maybe you're
> mistaking what curly brackets do (just separate a variable from
> concatenated text) vs what double quotes do (protect your variable from
> globbing, word splitting, and filename expansion).

I know that people they are not necessary, but try:
dummy='some text'
echo ${dummy}12
echo $dummy12

And yes, you said separate from concatenated text, but I have seen it
go wrong to often. And in a way find it also looking better.


> The use of `function foo {` is non-portable, use `foo() {` instead.

It is a bash script, so it is in my opinion the preferred way.


> When printing error messages (e.g. inside "giveError()") add `>&2` so
> the message goes to stderr instead of stdout.

Yes, I already noticed that blunder.

Cecil Westerhof

未讀,
2022年8月17日 中午12:44:072022/8/17
收件者:
Ed Morton <morto...@gmail.com> writes:

> On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
>> Ed Morton <morto...@gmail.com> writes:
>>
>>> On 8/16/2022 12:30 PM, Cecil Westerhof wrote:
>>> <snip>
>>>> I created a bash group on LinkedIn and there was a question about how
>>>> to learn to program in bash. So I wrote a script and an article
>>>> explaining the script with hopefully interesting tips for people how
>>>> to create their own scripts.
>>>> I just thought/hoped it could be interesting for people using this
>>>> newsgroup.
>>>
>>> Then I wish you had posted your script and article here and pointed
>>> people from LinkedIn here instead of doing it the other way around.
>> I do not think that will work. I love usenet, but we (users of usenet)
>> are a dying race. Most people do not even know it exists.
>>
>
> Usenet was just one example of an existing forum, if you don't like
> usenet

What in the sentence 'I love usenet' did you make think that I do not
like it?

Kenny McCormack

未讀,
2022年8月17日 中午12:52:332022/8/17
收件者:
In article <87sflu9...@munus.decebal.nl>,
Cecil Westerhof <Ce...@decebal.nl> wrote:
...
>> Usenet was just one example of an existing forum, if you don't like
>> usenet
>
>What in the sentence 'I love usenet' did you make think that I do not
>like it?

Cecil, you are trying to make sense of the ravings of a lunatic.

--
When someone tells me he/she is a Christian I check to see if I'm
still in possession of my wallet.

Ed Morton

未讀,
2022年8月17日 中午12:56:462022/8/17
收件者:
On 8/17/2022 11:01 AM, Cecil Westerhof wrote:
> Ed Morton <morto...@gmail.com> writes:
<snip>
>> The use of `function foo {` is non-portable, use `foo() {` instead.
>
> It is a bash script, so it is in my opinion the preferred way.

I see, so this apparently falls into the "but not rigorously" side of
your previous comment:

> In a way I like to confirm to POSIX. But not rigorously.

:-).

Obviously bash accepts either format and has no preference/distinction
in itself so which one to use in a bash script just depends on which
other shell(s) you want your code to be compatible with.

If you want your code to be compatible with ksh then, depending on what
you want it to mean in an AT&T implementation of ksh, you should use
`function name` or `name ()`, with zsh then you can use either, or with
all Bourne-derived shells including zsh and ksh (with caveats) then
`name ()`.

If you don't care about any of that then why not just make it the most
portable, `name ()`, especially since you're providing it as an example
for others to emulate and they might be trying to implement similar
functions in other shells.

Ed.


Ed Morton

未讀,
2022年8月17日 中午12:57:192022/8/17
收件者:
On 8/17/2022 11:39 AM, Cecil Westerhof wrote:
> Ed Morton <morto...@gmail.com> writes:
>
>> On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
>>> Ed Morton <morto...@gmail.com> writes:
>>>
>>>> On 8/16/2022 12:30 PM, Cecil Westerhof wrote:
>>>> <snip>
>>>>> I created a bash group on LinkedIn and there was a question about how
>>>>> to learn to program in bash. So I wrote a script and an article
>>>>> explaining the script with hopefully interesting tips for people how
>>>>> to create their own scripts.
>>>>> I just thought/hoped it could be interesting for people using this
>>>>> newsgroup.
>>>>
>>>> Then I wish you had posted your script and article here and pointed
>>>> people from LinkedIn here instead of doing it the other way around.
>>> I do not think that will work. I love usenet, but we (users of usenet)
>>> are a dying race. Most people do not even know it exists.
>>>
>>
>> Usenet was just one example of an existing forum, if you don't like
>> usenet
>
> What in the sentence 'I love usenet' did you make think that I do not
> like it?
>

I mean "like" in the context of where to post your script.

Cecil Westerhof

未讀,
2022年8月17日 中午12:59:162022/8/17
收件者:
Aragorn <thor...@telenet.be> writes:

> I agree with that, and I myself always write my scripts in the most
> portable way, but the OP has very clearly indicated that it is a bash
> script, and that it's specifically intended for use in GNU/Linux, where
> GNU bash is still the main shell.

I have heard of people that used my bash library on a non Linux
system, but it is a very small minority. I myself work only with
Linux.

Cecil Westerhof

未讀,
2022年8月17日 中午12:59:172022/8/17
收件者:
gaz...@shell.xmission.com (Kenny McCormack) writes:

> In article <871qtea...@munus.decebal.nl>,
> Cecil Westerhof <Ce...@decebal.nl> wrote:
> ...
>>> awk '{p=$4} END{print substr(p, 1, length(p) - 1)}'
>>
>>For me it works, but I should implement something like this then.
>
> Or you could just use either mawk or gawk, which are known to work.
>
> I always recommend against using plain old "awk" in a script, b/c you never
> know what you are going to get.
>
> Until fairly recently, using plain "awk" under Solaris got you a very old,
> essentially non-functional version of AWK.

But awk is much more often installed as mawk, or gawk. So that is why
I always use awk. Until know no complaints. But maybe that is because
nobody uses my scripts. :-D

On my system I have both mawk and gawk and awk is silently just gawk.

Cecil Westerhof

未讀,
2022年8月17日 下午1:44:072022/8/17
收件者:
Ed Morton <morto...@gmail.com> writes:

> If you want your code to be compatible with ksh then, depending on
> what

No, I do not want that.


> If you don't care about any of that then why not just make it the most
> portable, `name ()`, especially since you're providing it as an example
> for others to emulate and they might be trying to implement similar
> functions in other shells.

You would have preferred that everyone used BASICODE?
https://en.wikipedia.org/wiki/BASICODE

Cecil Westerhof

未讀,
2022年8月17日 下午1:44:082022/8/17
收件者:
Ed Morton <morto...@gmail.com> writes:

> On 8/17/2022 11:39 AM, Cecil Westerhof wrote:
>> Ed Morton <morto...@gmail.com> writes:
>>
>>> On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
>>>> Ed Morton <morto...@gmail.com> writes:
>>>>
>>>>> On 8/16/2022 12:30 PM, Cecil Westerhof wrote:
>>>>> <snip>
>>>>>> I created a bash group on LinkedIn and there was a question about how
>>>>>> to learn to program in bash. So I wrote a script and an article

And this is why I posted it there and not here.


>>>>>> explaining the script with hopefully interesting tips for people how
>>>>>> to create their own scripts.
>>>>>> I just thought/hoped it could be interesting for people using this
>>>>>> newsgroup.
>>>>>
>>>>> Then I wish you had posted your script and article here and pointed
>>>>> people from LinkedIn here instead of doing it the other way around.
>>>> I do not think that will work. I love usenet, but we (users of usenet)
>>>> are a dying race. Most people do not even know it exists.
>>>>
>>>
>>> Usenet was just one example of an existing forum, if you don't like
>>> usenet
>> What in the sentence 'I love usenet' did you make think that I do not
>> like it?
>>
>
> I mean "like" in the context of where to post your script.

I like to post it here, but it is not only about like, it is also
about being effective. It is not opportune to answer a question in the
LinkedIn bash group on usenet.

Ed Morton

未讀,
2022年8月17日 下午2:22:282022/8/17
收件者:
I didn't suggest doing that. I suggested posting your script on some
commonly used existing forum where it could help many people and
answering the question where it was asked but point them to the script
on that common forum rather than doing the opposite of posting your
script on LinkedIn and then posting messages on other forums directing
people to LinkedIn.

Ed.

Ed Morton

未讀,
2022年8月17日 下午2:27:002022/8/17
收件者:
On 8/17/2022 12:41 PM, Cecil Westerhof wrote:
> Ed Morton <morto...@gmail.com> writes:
>
>> If you want your code to be compatible with ksh then, depending on
>> what
>
> No, I do not want that.
>
>
>> If you don't care about any of that then why not just make it the most
>> portable, `name ()`, especially since you're providing it as an example
>> for others to emulate and they might be trying to implement similar
>> functions in other shells.
>
> You would have preferred that everyone used BASICODE?
> https://en.wikipedia.org/wiki/BASICODE
>

I didn't suggest doing that. I suggested that when writing code that you
intend for many people to read and learn from where your target shell is
completely indifferent to multiple equivalent syntaxes, given a choice
of writing that code in a way that's portable to many shells or in a way
that's only portable to a small subset of shells, it's better to write
it in the way that's portable to many shells.

Ed.

Percival John Hackworth

未讀,
2022年8月17日 下午3:23:352022/8/17
收件者:
LinkEdIn is NOT the place I go to for technical help. The places already
mentioned here
are better for reaching more people, if that's truly what you want to do. But
your arguing
that point makes me think there's some alterior motive going on here. The more
you push
it the more that makes my point.
--
DeeDee, don't press that button! DeeDee! NO! Dee...

Janis Papanagnou

未讀,
2022年8月17日 下午4:20:102022/8/17
收件者:
On 17.08.2022 16:40, Ed Morton wrote:
> On 8/17/2022 5:32 AM, Janis Papanagnou wrote:
>> On 16.08.2022 19:37, Cecil Westerhof wrote:
>
> <snip>
>
>> Since you want only the last line of the df output you can let awk do
>> that job; at the end of processing the last processed input line is
>> still available in the END section, a simple change
>>
>> df -BG $(dirname $1) |
>> awk 'END {print substr($4, 1, length($4) - 1)}'
>
> At the end of processing the last processed input line is not guaranteed
> to still available in the END section.
>
> The value of $4 or any other field or $0 is undefined (by POSIX)

Hi Ed, I'm not sure that matters here, given that bash is specified and
since the 'df -B' is also non-standard. So we can probably assume to be
safe in this context here with that implicit assumption. But, sure, for
other contexts that may be necessary, and it can be easy checked whether
it works or not in any environment.

> in the
> END section. In some awk variants it will be the $4 from the last record
> read as you want, but in others it'll be null, and in others still it
> could be anything else. To do what you show above portably in all awks
> would be:
>
> awk '{p=$4} END{print substr(p, 1, length(p) - 1)}'

You can still use the integer conversion to simplify the command

awk '{p=$4} END {print 0+p}'


Janis

>
> Regards,
>
> Ed.
>

Kaz Kylheku

未讀,
2022年8月17日 下午4:35:562022/8/17
收件者:
On 2022-08-16, Cecil Westerhof <Ce...@decebal.nl> wrote:
> For people who know Bash, but like to learn write (better) scripts I
> wrote an article about a script I wrote to create and add a swapfile:
> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
>
> You can get the script here:
> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwapFile.sh

A script like this is a good idea.

The last time I needed to make a swap file on Linux was at least fifteen
years ago. I can spew the commands to do it in my sleep: dd to create
the file, then mkswap and swapon.

Yet, I never "chmod 0600" on the file; and root's umask is often 022,
leaving files readable to others.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Janis Papanagnou

未讀,
2022年8月17日 下午4:46:072022/8/17
收件者:
On 17.08.2022 17:40, Cecil Westerhof wrote:
> Janis Papanagnou <janis_pa...@hotmail.com> writes:
>> On 16.08.2022 19:37, Cecil Westerhof wrote:
>>> Cecil Westerhof <Ce...@decebal.nl> writes:
>>>
>
>>> function getFreeGB {
>>> df -BG $(dirname $1) | \
>>> tail -n 1 | \
>>> awk '{print substr($4, 1, length($4) - 1)}'
>>> }
>>
>> In scripting the backslashes as a line continuation are a bad concept
>> since you don't see whether there's whitespace characters (other than
>> the newline character) there. Specifically a final pipe symbol doesn't
>> need any explicit textual line continuation so it can be anyway just
>> omitted.
>
> I know that you have to be careful that the backslash is the last
> character on the line, but I find it important that lines (if
> possible) are less as 80 characters.
> I did not know that the final pipe symbol does not need an explicit
> context. That is going to make my live easier.

That's often (always?) possible in cases where an incomplete syntactical
expression is given; works, for example, also with conditional commands

[[ -f "$f" ]] &&
rm "$f"

Long pipelines and conditional commands are the most common cases [in
my scripts] where long lines often appear and should be folded.

>
>> Below I am wondering why you are not consistently using braces when
>> expanding variables; we see ${0} and $2, and we see ${_gbFree} and
>> $_gb. I think this is confusing for folks that are learning shell -
>> as I understood that this was the (or one) intention of your post.
>> Whatever you prefer, but mixing is not a good thing as a paragon.
>
> Oops, that I used ${0} was certainly wrong. :'-(

Erm, ${0} is not "wrong", I just meant that it's inconsistently used.

>
> Let me explain. In the past people where really annoyed by me using
> braces. "It is not necessary." But there are some cases where they are
> important. That is why I decided that when the length of a name is not
> more as 4 characters long I will not use braces and otherwise I will.
> But I should explain that.

In my scripts I use generally braces, to be consistent, and to make
it work in any of the cases where it's necessary. Examples for that;
composition of variable name with alphanumeric suffix: ${var}_suffix,
or with positional parameters for numbers greater than 9: ${12}, or
to be syntactically consistent with the complex string operations,
e.g. ${var/x/y}, ${#str}, ${a[@]}, etc.

>
>> Since you're using a modern shell like bash (and obviously don't
>> restrict to POSIX)
>
> I am a bit on the fence with that. In a way I like to confirm to
> POSIX. But not rigorously. For example I use long options, but
> mentions what the corresponding short ones are. Handy for people that
> have a POSIX compliant awk.

First please note that my comment here was just an _observation_,
not a valuation or criticism. From the observation I derived that
my further suggestions needed not be POSIX'ly portable.

For me, POSIX is far too restricted to be happily using it. (Unless
explicitly necessary for portability) I restrict to it mainly only
if my deviations from POSIX are insignificant and I can omit them
without loss. On the other hand - note I'm using ksh - I often use
the ksh extensions if they are also supported by bash and zsh, and
I use the major extensions of ksh that are not available in bash
if unavoidable (e.g. built-in floating point arithmetic [without
falling back to external processes], or complex things like the
type system, discipline functions, and similar).

Janis

Janis Papanagnou

未讀,
2022年8月17日 下午4:51:562022/8/17
收件者:
On 17.08.2022 18:50, Cecil Westerhof wrote:
> Aragorn <thor...@telenet.be> writes:
>
>> I agree with that, and I myself always write my scripts in the most
>> portable way, but the OP has very clearly indicated that it is a bash
>> script, and that it's specifically intended for use in GNU/Linux, where
>> GNU bash is still the main shell.
>
> I have heard of people that used my bash library on a non Linux
> system, but it is a very small minority. I myself work only with
> Linux.

You have specified an interpreter as first line #!/usr/bin/env bash
so I assume it's an executable - or at least that's a documentation
for users to not let it run under different shells. - That's fine.

Janis

Cecil Westerhof

未讀,
2022年8月17日 下午5:44:072022/8/17
收件者:
I sometimes got flack for that also. "That is overkill." But bash can
(or at least could) be on different places. While /usr/bin/env should
exist on all systems. (Could be through a link.) And in this way my
bash scripts should run on all systems where bash is installed.

Cecil Westerhof

未讀,
2022年8月17日 下午5:44:072022/8/17
收件者:
Janis Papanagnou <janis_pa...@hotmail.com> writes:

> On 17.08.2022 17:40, Cecil Westerhof wrote:
>> Oops, that I used ${0} was certainly wrong. :'-(
>
> Erm, ${0} is not "wrong", I just meant that it's inconsistently used.

Wrong in the sense that I only use braces when a variable name is
longer as four characters. ;-)


>> Let me explain. In the past people where really annoyed by me using
>> braces. "It is not necessary." But there are some cases where they are
>> important. That is why I decided that when the length of a name is not
>> more as 4 characters long I will not use braces and otherwise I will.
>> But I should explain that.
>
> In my scripts I use generally braces, to be consistent, and to make
> it work in any of the cases where it's necessary. Examples for that;
> composition of variable name with alphanumeric suffix: ${var}_suffix,
> or with positional parameters for numbers greater than 9: ${12}, or
> to be syntactically consistent with the complex string operations,
> e.g. ${var/x/y}, ${#str}, ${a[@]}, etc.

Well, maybe I can change my ways again. But honestly I find ${0}
looking a bit weird. That is why I find it so strange I used it.


> without loss. On the other hand - note I'm using ksh - I often use
> the ksh extensions if they are also supported by bash and zsh, and
> I use the major extensions of ksh that are not available in bash
> if unavoidable (e.g. built-in floating point arithmetic [without
> falling back to external processes], or complex things like the
> type system, discipline functions, and similar).

Yes, floating point arithmetic is something I sometimes miss very
much.

Cecil Westerhof

未讀,
2022年8月17日 下午5:59:072022/8/17
收件者:
Kaz Kylheku <480-99...@kylheku.com> writes:

> On 2022-08-16, Cecil Westerhof <Ce...@decebal.nl> wrote:
>> For people who know Bash, but like to learn write (better) scripts I
>> wrote an article about a script I wrote to create and add a swapfile:
>> https://www.linkedin.com/pulse/script-add-swap-file-cecil-westerhof
>>
>> You can get the script here:
>> https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/addSwapFile.sh
>
> A script like this is a good idea.

I thought so. To use and as an exercise.
And an added benefit is that I learned something along the way.

One of the things I learned is that readonly eats your exit code. That
is why I now use:
declare -i _gbFree
_gbFree=$(getFreeGB "${_swapFile}")
readonly _gbFree

I find it to verbose, but when it is needed to circumvent a bug …


> The last time I needed to make a swap file on Linux was at least fifteen
> years ago. I can spew the commands to do it in my sleep: dd to create
> the file, then mkswap and swapon.

I almost never have done it. I had to look it up. That made me think
it would be nice to have it. This combined with a question about how
to become more proficient in bash made me write it.


> Yet, I never "chmod 0600" on the file; and root's umask is often 022,
> leaving files readable to others.

With all the bad possibilities.


I was told that the group should be also disk. (Did not see that on
the internet. Maybe should do a search on that.) But that is the nice
thing about a script: when you learn of extra restrictions it is very
easy to apply them and you have not to be afraid that you will forget
them.

As they say: things you do seldom you should automate.

Janis Papanagnou

未讀,
2022年8月17日 晚上8:12:552022/8/17
收件者:
On 17.08.2022 23:37, Cecil Westerhof wrote:
>
> Well, maybe I can change my ways again. But honestly I find ${0}
> looking a bit weird. That is why I find it so strange I used it.

Frankly, I don't use ${1} etc., I use $1. (In case of $0 it's often
only used in context of ${0##*/}, i.e. to strip the path component.)
Why so? Because it's rare in practice that you need hard access to
so many positional parameters; design-wise there's usually better
options to achieve that. One sometimes used special case is access
to the last element where [the classical way] you need braces; e.g.
in expressions like eval last=\${$#} but then there's also the
newer (non-standard) syntax ${@: -1:1} available in some shells.

Janis

Janis Papanagnou

未讀,
2022年8月18日 清晨5:07:522022/8/18
收件者:
On 18.08.2022 02:12, Janis Papanagnou wrote:
> On 17.08.2022 23:37, Cecil Westerhof wrote:
>>
>> Well, maybe I can change my ways again. But honestly I find ${0}
>> looking a bit weird. That is why I find it so strange I used it.
>
> Frankly, I don't use ${1} etc., I use $1. [...]

As it occurred to me, this is not quite true. I have the habit to
map the meaningless numbered parameters to names at the top of
the script (same with function parameters), thereby also forcing
a test of mandatory parameters, as in

filename=${1:?} amount=${2:?} reverse=${3}

and write the optional parameters (for consistency) also with
braces.

The case that I use $1 without braces is thus rare and mostly
done only in small ad hoc test scripts or ad hoc commands.

An exception is "$@", $?, etc.

Janis

Geoff Clare

未讀,
2022年8月18日 上午9:11:082022/8/18
收件者:
Kenny McCormack wrote:

> Until fairly recently, using plain "awk" under Solaris got you a very old,
> essentially non-functional version of AWK.

Only if you didn't set your PATH appropriately. (I.e. didn't put
/usr/xpg4/bin before /bin or /usr/bin).

--
Geoff Clare <net...@gclare.org.uk>

Anssi Saari

未讀,
2022年8月19日 上午8:49:572022/8/19
收件者:
Cecil Westerhof <Ce...@decebal.nl> writes:

>> awk '{p=$4} END{print substr(p, 1, length(p) - 1)}'
>
> For me it works, but I should implement something like this then.

Why not just use stat to get the amount of free space on the file
system? Seems more reasonable than parsing df output. Although stat
seems to give free space in blocks so one needs to do extra work to find
out the block size too and then a bit of arithmetic to get
gigabytes. But it might avoid the issue on btrfs mentioned before.

Also I wonder if a pagefile actually needs to prewritten out like that
with dd or if creating a sparse file with truncate would be enough.

Lew Pitcher

未讀,
2022年8月19日 上午9:30:522022/8/19
收件者:
On Fri, 19 Aug 2022 15:49:52 +0300, Anssi Saari wrote:
[snip]

> Also I wonder if a pagefile actually needs to prewritten out like that
> with dd or if creating a sparse file with truncate would be enough.

From swapon(8):
"You should not use swapon on a file with holes.

The swap file implementation in the kernel expects to be able to write
to the file directly, without the assistance of the filesystem. This
is a problem on preallocated files (e.g. fallocate(1)) on filesystems
like XFS or ext4, and on copy-on-write filesystems like btrfs. It is
recommended to use dd(1) and /dev/zero to avoid holes on XFS and ext4."

HTH
--
Lew Pitcher
"In Skills, We Trust"

gerg

未讀,
2022年8月23日 凌晨12:18:592022/8/23
收件者:
Cecil Westerhof <Ce...@decebal.nl> wrote:
>
>As they say: things you do seldom you should automate.
>

I have a different viewpoint. Things you do often should be
automated. Things you do seldom should be documented.

Writing a wiki page to document a procedure takes much less time
than writing/testing/bugfixing automation for the procedure. Both
repay the time spent creating them in small increments each time
the procedure is repeated.

The long time spent automating the steps will take 5 or 6 repeats
(or more) to repay. A seldom-used procedure may never reach that
point, but an often-used procedure will. The short time documenting
the steps will take only 1 or 2 repeats to repay - far more achievable
by a seldom-used procedure.

-Greg
--
::::::::::::: Greg Andrews ::::: ge...@panix.com :::::::::::::
I have a map of the United States that's actual size.
-- Steven Wright

Janis Papanagnou

未讀,
2022年8月23日 清晨5:21:012022/8/23
收件者:
On 23.08.2022 06:18, gerg wrote:
> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>
>> As they say: things you do seldom you should automate.
>>
>
> I have a different viewpoint. Things you do often should be
> automated. Things you do seldom should be documented.
>
> Writing a wiki page to document a procedure takes much less time
> than writing/testing/bugfixing automation for the procedure.

It depends (see below), and I doubt it.

> Both
> repay the time spent creating them in small increments each time
> the procedure is repeated.
>
> The long time spent automating the steps will take 5 or 6 repeats
> (or more) to repay.

It depends (see below), and I doubt it.

> A seldom-used procedure may never reach that
> point, but an often-used procedure will. The short time documenting
> the steps will take only 1 or 2 repeats to repay - far more achievable
> by a seldom-used procedure.

It depends (see below), and I doubt it.

Above you have a couple hypotheses with a couple numbers added that
leave me with the impression of arbitrariness; for sure, at least,
they don't match with my experience if I see what appears to me to
be on closer examination "the whole [or rather an extended] picture".

So let me add a third opinion. - Automate it [always] if you can.

A few observations...
The posted script is implementing in a straightforward way a task;
it's easy to write it down. A procedure can be a written document,
or, well, a coded procedure. Documentation (where necessary) can be
added in-line; if that's necessary. Documenting separately supports
inconsistencies; you need a meta-procedure (or know to rely on the
folks [or yourself] doing the procedure). Any documentation doesn't
alleviate the necessity to code the task if you need it at some time.
Simple one-time tasks can be just throw-away scripts, but how sure
can one be that we don't need to use it again? - who decides that?
If you perform a task a second time you may think about scripting it,
if you perform it a third time and have no script that automate the
task it's all your own fault. It doesn't hurt to put a one-time
procedure in a file to have it available for another time. Documents
are sometimes (regularly? - very much depending on the sort of the
software and the application cases) forgotten or ignored, especially
if it's in another place and/or on another medium. To create sensible
documentation proficiently get a professional. To code a (quality)
script proficiently get a professional. Code and documentation are
not necessarily two different things. There are programming languages
and also separate tools existing that create documentation together
with and/or from the code. Some shells (ksh) do also support usage
documentation and extended man page creation from the getopts code
specification. To get any procedure right (on paper or as code) you
have to invest time; if a procedure is not obvious you have to try
it using code and not document something that actually doesn't work,
is incomplete, or plain wrong. Any coded procedure can be incrementally
enhanced, and immediately tested and validated. Any procedure on paper
has no inherent test means or validity by itself; it's non-operational
paper.

Janis

0 則新訊息