On Sun, Jan 25, 2015 at 08:11:41PM -0800, garegi...@gmail.com wrote:
> As a programming language which paradigms does bash support. Declarative,
> procedural, imperative?
This belongs on help-b...@gnu.org so I'm Cc'ing that address.
Shell scripts are procedural.
The control structures are while
I don't understand what this is about, but I hope you will.
Would you please ack receipt of the message? Then I presume you will DTRT.
--- Start of forwarded message ---
X-Spam-Status: No, score=2.6 required=5.0 tests=BAYES_50,
FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FROM_LOCAL_
On 26/01/15 13:43, Greg Wooledge wrote:
> On Sun, Jan 25, 2015 at 08:11:41PM -0800, garegi...@gmail.com wrote:
>> As a programming language which paradigms does bash support. Declarative,
>> procedural, imperative?
>
> This belongs on help-b...@gnu.org so I'm Cc'ing that address.
>
> Shell scrip
> On Jan 26, 2015, at 8:18 AM, Chet Ramey wrote:
[. . .]
> Do you intend to say that this should affect how the `Type-In' addendum to
> the GPL is written or interpreted? If so, how is it different from any
> publishing requirements that exist on a shell script?
These requirements only dictat
> Mr. Ramey, I already pointed that out to Mr. Stallman. I found that out from
> testing a similar technique using Python.
How is a heredoc "object code"? You're just passing the source to the bash
interpreter through a pipe, but it's still source code.
A here-document isn't object code; I mean object code you edit in the editor
provided in or referenced by the aggregate and /then/ execute after it has been
saved, like you would save a plain text file.
--
Sent from my iPod
On Jan 26, 2015, at 9:05 AM, Eduardo A. Bustamante López
wrote:
>>
And, by the way, the here-document is source code; what you type into that
editor (in hexadecimal, decimal, or octal form) is object code already compiled.
--
Sent from my iPod
> On Jan 26, 2015, at 9:07 AM, Ryan Cunningham wrote:
>
> A here-document isn't object code; I mean object code you
Hello everyone,
This is my first appearance to the mailing list and i am looking for a
solution regarding variable monitoring in bash scripts. What i meant by
variable monitoring is to periodically read variable values and store it
to a file for later processing. The quickest and easiest way i
On Mon, Jan 26, 2015 at 04:29:04PM +0100, Michael Mehari wrote:
> What i meant by
> variable monitoring is to periodically read variable values and store it
> to a file for later processing.
> The first approach i looked was to export this variable into the child
> process and periodically stor
On Jan 26, 2015, at 8:35 AM, Ryan Cunningham wrote:
> These requirements only dictate how the code is provided. They dictate that
> source code must somehow be provided, even if the program is published in
> object code form; how it must be provided; and other additional requirements
> that lo
On Mon, Jan 26, 2015 at 10:14:19AM -0800, Ryan Cunningham wrote:
> Sorry, I forgot to state that it could also be saved by an object code editor
> and loaded then like you would load any other program in object code.
Bash doesn't run object code, except in one very unusual situation:
a user-suppl
I mean that the program would be loaded in the same manner in which Bash would
execute any other object-code program that isn't loaded /into/ Bash as a
builtin, like "ls", "su", and "dirname", all from GNU Coreutils.
--
Sent from my iPod
> On Jan 26, 2015, at 10:25 AM, Greg Wooledge wrote:
>
On Mon, Jan 26, 2015 at 10:36:37AM -0800, Ryan Cunningham wrote:
> I mean that the program would be loaded in the same manner in which Bash
> would execute any other object-code program that isn't loaded /into/ Bash as
> a builtin, like "ls", "su", and "dirname", all from GNU Coreutils.
Bash doe
And that is exactly what I mean---running a separate program. Sorry for any
confusion.
On Mon, Jan 26, 2015 at 10:43 AM, Greg Wooledge wrote:
> On Mon, Jan 26, 2015 at 10:36:37AM -0800, Ryan Cunningham wrote:
> > I mean that the program would be loaded in the same manner in which Bash
> would ex
I'd suggest first investigating how bash works (read the source), before
claiming funky stuff. Bash interpretes *source code*, it doesn't matter how you
provide it. The only exception is what Greg specified.
Sorry, I apologize for all the confusion. I will try to remedy it here:
When you receive a program in *source code* form, you would type it into
Bash as follows:
cat <<'EOF' | tee [file name] | bash
type
your
script
here
EOF
Then Bash runs the script.
When you receive a program in *object code*
On Mon, Jan 26, 2015 at 01:32:21PM -0800, Ryan Cunningham wrote:
> When you receive a program in *object code* form, you would type it into an
> object code editor and then save it in a binary file.
Why? Is it 1982 again? Are we typing in 6502 machine code from a
glossy magazine?
In the 21st ce
First of all, it's 2015, not 1982. (By the way, I got my inspiration for
this from the July 1984 issue of *COMPUTE!* Magazine, which I got from the
OpenLibrary project of the Internet Archive.)
Second, the machine code we type in, *if we receive any,* will most likely
be 8086 machine code, not Mot
> I am proposing this as a possible alternative or complement to publication
> on the Internet to take into account those without Internet access, though
> those *with* Internet access also get the benefit.
So you want to publish stuff on the Internet for people that don't have access
to the Intern
No, no, not on the Internet---I mean in a paper magazine, which Internet users
can also get.
I'd like the machine code discussion to end.
--
Sent from my iPod
On Jan 26, 2015, at 3:03 PM, Eduardo A. Bustamante López
wrote:
>> I am proposing this as a possible alternative or complement to pu
I would also like the discussion on the GCC mailing list to end. The discussion
on /source/ code, however, should remain alive and well.
Sorry for all the confusion.
And by "type-in programs", I don't mean example programs like "Hello world"
programs. I mean real programs with real purpose.
Pr
These type-in programs can actually generate quicker rises in popularity of the
FSF and in total market share of GNU/Linux distributions as more and more
people are introduced by such programs (or the experience of typing them) to
the concept of free and open-source software. I mean, GNU/Linux's
22 matches
Mail list logo
