On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
> Ed Morton <mortonspam@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.

Ed Morton <mortonspam@gmail.com> writes:

> On 8/16/2022 12:37 PM, Cecil Westerhof wrote:
>> Cecil Westerhof <Cecil@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
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Ed Morton <mortonspam@gmail.com> writes:

> On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
>> Ed Morton <mortonspam@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?

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

In article <87sflu9651.fsf@munus.decebal.nl>,
Cecil Westerhof <Cecil@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.

On 8/17/2022 11:01 AM, Cecil Westerhof wrote:
> Ed Morton <mortonspam@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.

On 8/17/2022 11:39 AM, Cecil Westerhof wrote:
> Ed Morton <mortonspam@gmail.com> writes:
>
>> On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
>>> Ed Morton <mortonspam@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.

Aragorn <thorongil@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
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <871qteamv5.fsf@munus.decebal.nl>,
> Cecil Westerhof <Cecil@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
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Ed Morton <mortonspam@gmail.com> writes:

> On 8/17/2022 11:39 AM, Cecil Westerhof wrote:
>> Ed Morton <mortonspam@gmail.com> writes:
>>
>>> On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
>>>> Ed Morton <mortonspam@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.

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

Ed Morton <mortonspam@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
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

On 8/17/2022 12:29 PM, Cecil Westerhof wrote:
> Ed Morton <mortonspam@gmail.com> writes:
>
>> On 8/17/2022 11:39 AM, Cecil Westerhof wrote:
>>> Ed Morton <mortonspam@gmail.com> writes:
>>>
>>>> On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
>>>>> Ed Morton <mortonspam@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.
>

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.

On 8/17/2022 12:41 PM, Cecil Westerhof wrote:
> Ed Morton <mortonspam@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.

On 17-Aug-2022 at 11:22:23AM PDT, "Ed Morton" <mortonspam@gmail.com> wrote:

> On 8/17/2022 12:29 PM, Cecil Westerhof wrote:
>> Ed Morton <mortonspam@gmail.com> writes:
>>
>>> On 8/17/2022 11:39 AM, Cecil Westerhof wrote:
>>>> Ed Morton <mortonspam@gmail.com> writes:
>>>>
>>>>> On 8/17/2022 10:48 AM, Cecil Westerhof wrote:
>>>>>> Ed Morton <mortonspam@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.
>>
>
> 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.

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...

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.
>

On 2022-08-16, Cecil Westerhof <Cecil@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

On 17.08.2022 17:40, Cecil Westerhof wrote:
> Janis Papanagnou <janis_papanagnou@hotmail.com> writes:
>> On 16.08.2022 19:37, Cecil Westerhof wrote:
>>> Cecil Westerhof <Cecil@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

On 17.08.2022 18:50, Cecil Westerhof wrote:
> Aragorn <thorongil@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

Janis Papanagnou <janis_papanagnou@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
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Janis Papanagnou <janis_papanagnou@hotmail.com> writes:

> On 17.08.2022 18:50, Cecil Westerhof wrote:
>> Aragorn <thorongil@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.

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
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Kaz Kylheku <480-992-1380@kylheku.com> writes:

> On 2022-08-16, Cecil Westerhof <Cecil@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.

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

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

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

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 <netnews@gclare.org.uk>

Cecil Westerhof <Cecil@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.

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"