Hi,
short summary for the impatient readers: the following text dives into the
subtile differences between errexit (set -e) and exit status in shell scripting
Am Mon, 11 Jan 2016 05:14:18 -0500
schrieb Daniel Dickinson :
> I did one other test I hadn't thought of originally:
>
> #!/bin/sh
>
>
I did one other test I hadn't thought of originally:
#!/bin/sh
set -e
/bin/false && /bin/false
echo "not killed"
displays "not killed", so there still the issue that unlike if..then
with set -e, && fails to exit on error condition (for the purposes of
set -e it's like there is an implicit |
Hmmm...actually this may be a case of an old non-POSIX conformant shell
I once had to work in.
Anyway any modern POSIX-compliant shell doesn't have this issue.
Regards,
Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lis
Actually I must have been smoking something when I thought I saw that
problem (and no I don't actually). I think it must have been in
combination with some other error that I misremembered.
I just checked both bash and ash (and the docs) and they 'do the right
thing'.
Regards,
Daniel
On 1
Hi,
On 10/01/16 06:42 AM, bittorf wireless )) Bastian Bittorf wrote:
+
+start() {
+ if [ -e /dev/rtc ]; then
+ hwclock -s
please use the short form [ -e /dev/rtc ] && ...
Per private mail I've learned this is the current codebase standard, so
will follow that, but the r
Hi,
On Sonntag, 10. Januar 2016, Daniel Dickinson wrote:
> I had assumed it was automatic detection, (hence the comments about
> Patchwork), not something someone has added as their own personal
> excessively OCD-esque requirements.
I follow this list very loosely (= I read the mails very quickly
On 10/01/16 06:11 AM, John Crispin wrote:
On 10/01/2016 11:32, Daniel Dickinson wrote:
I'm sure this has been discussed to death, but having patchwork be a
knob isn't the answer.
at which point did patchwork get part of the equation ?
I had assumed it was an automatic detection from a prog
On 10/01/16 06:30 AM, Hartmut Knaack wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Daniel Dickinson schrieb am 10.01.2016 um 11:32:
And yes you could make a regex that detect any sets of 8 spaces before
non-whitespace text, but that seems like a lot of effort for no good
reason, when n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Daniel Dickinson schrieb am 10.01.2016 um 11:32:
> And yes you could make a regex that detect any sets of 8 spaces before
> non-whitespace text, but that seems like a lot of effort for no good
> reason, when not dealing with Makefiles.
>
> Anythin
On 10/01/2016 11:32, Daniel Dickinson wrote:
> I'm sure this has been discussed to death, but having patchwork be a
> knob isn't the answer.
at which point did patchwork get part of the equation ?
i simple looked over the mails in my inbox in the morning and saw that
there are 8 leading spaces
And yes you could make a regex that detect any sets of 8 spaces before
non-whitespace text, but that seems like a lot of effort for no good
reason, when not dealing with Makefiles.
Anything that applies a *hard* rule about whitespace is broken -
whitespace shouldn't be getting converted unless
Hi,
On 10/01/16 05:10 AM, Gert Doering wrote:
Hi,
On Sun, Jan 10, 2016 at 04:47:05AM -0500, Daniel Dickinson wrote:
I used git send-email so there shouldn't be any whitepspace mangling
issues, unless patchwork is to blame.
Over at openvpn-devel, we recently discovered that some versions of
M
Hi,
On Sun, Jan 10, 2016 at 04:47:05AM -0500, Daniel Dickinson wrote:
> I used git send-email so there shouldn't be any whitepspace mangling
> issues, unless patchwork is to blame.
Over at openvpn-devel, we recently discovered that some versions of
MS Exchange mangle whitespace for "mails in tra
Ok, if this is one I just sent, that makes no sense; git does not report
whitepace errors in git log -p, nor does the vim whitespace error
detector you emailed me detect a whitespace error, locally.
I used git send-email so there shouldn't be any whitepspace mangling
issues, unless patchwork i
On 10/01/2016 08:16, open...@daniel.thecshore.com wrote:
> +else
whitespace error
> + local curtime="$(date +%s)"
> + lo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/m
From: Daniel Dickinson
On systems that have an RTC prefer it to the file-based
time fixup (i.e. use hwclock when there is a permanent
clock instead of the faked up time logic that is needed
when there is not RTC).
Signed-off-by: Daniel Dickinson
---
package/base-files/files/etc/init.d/sysfixti
* open...@daniel.thecshore.com [17.12.2015
10:39]:
> From: Daniel Dickinson
>
> On systems that have an RTC prefer it to the file-based
> time fixup (i.e. use hwclock when there is a permanent
> clock instead of the faked up time logic that is needed
> when there is not RTC).
whats the differe
From: Daniel Dickinson
On systems that have an RTC prefer it to the file-based
time fixup (i.e. use hwclock when there is a permanent
clock instead of the faked up time logic that is needed
when there is not RTC).
Signed-off-by: Daniel Dickinson
---
package/base-files/files/etc/init.d/sysfixti
18 matches
Mail list logo
