(OffTopic,) Gnu-Environment restrictions (was Re: Question )

[L A Walsh]

Bob Proulx wrote:

Robert Elz wrote:
  

But any restrictions on the recipient mean that the software is not
really free, and that includes nonsense like requiring users to
redistribute the sources to anyone who wants it.  That's not
freedom, that's an obligation (serfdom - you have to do my work for
me.)



That is simply nonsense.
  

---
   [This is a "devil's advocate" type piece, please don't
think it implies any personally held beliefs.  :-) ]

   Not really -- if one first examines the nature of 'freedom'.
I.e. what are we free to do?  Can we flap our arms and fly like
a bird?  Not in our "reality".  In every environment there are
restrictions imposed by the nature of the environment.  Often,
but not always, these are called "natural laws".  They are
conditions which everyone accepts as "natural" and are almost
never referred to as "restrictions".

   If one looks at the nature of any environment, one can see
that all environments that are describable have a set of "natural
laws" that are required for that environment to exist.

   The GNU license provides for a slightly modified reality
that allows for SW to be "free" under many conventional definitions,
however, the Gnu environment, like any environment has its own
set of "natural laws" that are needed for the it to exist.

   The Gnu environments or "realities" allow freedom within
their environment.  Does that mean they are absolutely without
restriction?  No -- but I'd argue that any shared-reality must
have restrictions for the reality to exist.  In that respect,
there is "freedom" within the Gnu environment that isn't available
in the conventional environment with the trade-off that one
accepts the Gnu-environmental "boundaries" just as such boundaries
exist in conventional "environments" (or realities).  It would
would be subjective to define one reality as more or less free
than any other environment -- they are really, just "different".

:-)

-l

Builtin echo interrupted by WINCH

[Egmont Koblinger]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/build/bash-IrsGKQ/bash-4.4=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-no-pie -Wno-parentheses -Wno-format-security
uname output: Linux blacky 4.13.0-11-generic #12-Ubuntu SMP Tue Sep 12
16:03:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 12
Release Status: release

Description:

Problem 1.

For performance testing, I wanted to create a directory with 2M files.
I typed these commands in an interactive shell:

mkdir /tmp/huge
cd /tmp/huge
for i in {1..200}; do echo $i; done | xargs touch

While I waited unpatiently for the command to complete, I began
resizing my terminal emulator window. As in most graphical environment
nowadays, I have "opaque" resize, the app (terminal emulator in this
case) gets resized multiple times as I move my mouse around.

In approx 50% of the cases where the terminal emulator actually
changed its size (measured in characters), bash printed this:

bash: echo: write error: Interrupted system call

Correspondingly, some of the files (exactly as many as the number of
error messages) were not created.

Problem 2.

I realized involving a "for" loop was too complicated, I should've
gone with a simpler command:

echo {1..200} | xargs touch

So I tried this as well.

This time the error was only printed once when the command completed,
but a good 10.000-ish files were not created.

Plus, a few files named like "156562156707" or "232886233609" were
created erroneously. These are two relatively closeby (a few hundreds
apart) numbers concatenated without a space.

Is there anything bash could do to prevent incorrect behavior of its
built-in commands when a SIGWINCH is encountered? And of course I
don't mean the "echo" command only.

Thanks a lot,
egmont