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,
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 scripts are
On Jan 26, 2015, at 8:18 AM, Chet Ramey chet.ra...@case.edu 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
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 wool...@eeg.ccf.org 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
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.
On Jan 26, 2015, at 8:35 AM, Ryan Cunningham rvskmbr...@gmail.com 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
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 store it
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
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 rvskmbr...@gmail.com wrote:
A here-document isn't object code; I
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
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
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
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
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.
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
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 dual...@gmail.com
wrote:
I am proposing this as a possible alternative or
19 matches
Mail list logo