Best way to do server side tasks with new ISP

[ccc31807]

And I would also like to be able to implement a simple form that would have
its results emailed to me, which of course is a common task, but I assumeI
would need a CGI application to do that.

Thanks for any advice you may be able to provide.

Please permit me to make a couple of late comments.

I am a heavy user of Perl in my job, which is mostly slicing and
dicing data. Perl is a special purpose tool which is exceptionally
good at its intended purpose: string handling. As most web apps are
applications of handling strings, Perl is exceptionally good at
writing web apps. It's also very good at database and networking
applications ... but don't think that Perl is a good general purpose
language, because it wasn't designed to be.

I'll be glad to share code with you privately if you will email me at /
c c c 3 1 8 0 7 at y a h o o dot c o m/. About 90 percent of the code
will be instantly recognizable to you as HTML, CSS, or JavaScript. The
other ten percent will probably strike you as obfuscated and obscure
Perl, but hey, Perl by nature is obfuscated and obscure, which is why
it's good at what it does.

CC

 

[Mart van de Wege]

But that iterates over the entire prototype chain:

http://yuiblog.com/blog/2006/09/26/for-in-intrigue/

If you use an object to iterate over, yes. If you feed it an array, it
works the same as Perl's foreach.

Of course, since you can add properties to just about anything, you can
never be sure if you're actually iterating over an array. Javascript is
a bit quirky in that. But to me, it feels remarkably close to Perl,
funnily enough.

Mart

 

[Mart van de Wege]

Bzzzt! Wrong. Arrays are objects in JS, so anything added to
Array.prototype or Object.prototype will show up in the Array's
properties.

Well yeah. It pays to read further than a single paragraph, doesn't it?

It does, doesn't it? I think it's having both hashes and lexical closure
that does it.

For me, the fact that objects are merely hashes of properties felt very
familiar. The canonical Perl object is conceptually not much
different. Of course, as soon as you start using prototypical
inheritance, Javascript shows its differences, but the starting point is
remarkably similar.

Mart

 

[Dr.Ruud]

Given the following line:

foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true

Produce the following output:

* An alphabetically sorted list of the values assigned to each variable
* The count of values assigned to each variable
* The result of foo * 27 + 3

perl -wle '
my $line =
"foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true";
my %par; push @{ $par{$1} }, $2 while $line =~ /([^=;]+)=([^;]+)/g;
print for sort map @$_, values %par; print "-"x20;
print for map scalar(@$_), values %par; print "-"x20;
print $par{foo}[0] * 27 + 3;
'

1
b
c
c
seven
true
yes
--------------------
1
3
1
1
1

 

[Charlton Wilbur]

[problem specification, with instructions to try solving it in C
and in Perl]

R> [code to solve the problem]

Well, yes, it isn't a particularly difficult problem, either in Perl or
in C. The point is that it's a couple dozen lines of Perl at most, and
probably closer to a couple hundred lines of C.

Charlton

 

[sln]

[problem specification, with instructions to try solving it in C

Given the following line:

foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true

Produce the following output:

* An alphabetically sorted list of the values assigned to each variable
* The count of values assigned to each variable
* The result of foo * 27 + 3

and in Perl]

R> [code to solve the problem]

Well, yes, it isn't a particularly difficult problem, either in Perl or
in C. The point is that it's a couple dozen lines of Perl at most, and
probably closer to a couple hundred lines of C.

Charlton

In no way, shape or form, is this a problem specification, nor anything of
any use to anything or anybody, et all.

You can't parse c/c++ with this simplistic approach.
You can't get from HERE -->"foo=1;" to HERE --> "bar=yes;".
You can't even get to HERE -->"foo=1;"

Alpha sorted list of "values" assigned to each variable? Whats that tell ya?
Count of values, here I assume you are adressing re-assignment, as if scope is not an issue.
Finally, the result of foo's multiplicity.

Are you desperately trying to be funny?

-sln

 

[Paul E. Schoen]

In no way, shape or form, is this a problem specification, nor anything
of
any use to anything or anybody, et all.

You can't parse c/c++ with this simplistic approach.
You can't get from HERE -->"foo=1;" to HERE --> "bar=yes;".
You can't even get to HERE -->"foo=1;"

Alpha sorted list of "values" assigned to each variable? Whats that tell
ya?
Count of values, here I assume you are adressing re-assignment, as if
scope is not an issue.
Finally, the result of foo's multiplicity.

Are you desperately trying to be funny?

Yes, I was very confused about what the point was. I have no idea why the
following line would ever need to be parsed in C, or in any other language:

foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true

Perhaps in a loosely typed language, "foo" would be assumed to be numeric,
and probably integer. "bar" might be assumed to be Boolean, although in "C"
that is really just an integer where "yes" would need to be predefined as
non-zero. "baz" would be undefined unless "b" and "c" were previously
defined. Same with "quux", where "seven" also needs to be defined, and then
it is assigned to nothing, which would be an error unless it was
specifically assigned to NULL or nil. And finally "submit" may be
predefined as a Boolean, and true must also have been defined.

I assume the given line is supposed to be a script which is to be
interpreted and then some operations are supposed to be done on that
process. Maybe in Perl and CGI there are reasons to do something like this,
but it has just further complicated my understanding and avoidance of the
language.

And the point of using fewer lines to accomplish the same thing is not very
beneficial if the code is difficult to understand. Delphi (Pascal) does
tend to be rather verbose, and I wish there were constructs like {} rather
than "Begin" and "End", but well-written code with liberal use of
indentation and whitespace make it easy to understand and maintain. "C" has
some operators that make for more compact code, but IMHO at the cost of
readability. Then Perl seems to be at another level of brevity that reminds
me of command line switches as used in MSDOS and even CP/M utilities like
the line editor "ed".

Paul

 

[Charlton Wilbur]

PES> Yes, I was very confused about what the point was. I have no
PES> idea why the following line would ever need to be parsed in C,
PES> or in any other language:

PES> foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true

Consider a list of CGI form parameters in a GET query string.

Charlton

 

[Charlton Wilbur]

sln> In no way, shape or form, is this a problem specification, nor
sln> anything of any use to anything or anybody, et all.

On the contrary, if you were half the programmer you claim to be, you
would recognize the rudimentary elements of CGI query string parsing.

sln> You can't parse c/c++ with this simplistic approach. You can't
sln> get from HERE -->"foo=1;" to HERE --> "bar=yes;". You can't
sln> even get to HERE -->"foo=1;"

Er, I'm not *trying* to parse C or C++, and I can, actually, parse the
string as specified in the problem.

sln> Alpha sorted list of "values" assigned to each variable? Whats
sln> that tell ya? Count of values, here I assume you are adressing
sln> re-assignment, as if scope is not an issue. Finally, the
sln> result of foo's multiplicity.

The point of the example, as noted above, was to produce an example
problem that included the more basic elements of CGI processing, and in
particular those that would demonstrate the annoyances with using C to
write CGI-handling scripts. The original querent asked why Perl was
used in preference to C for early web programming, and I thought a
concrete example would be more useful than a history lesson.

sln> Are you desperately trying to be funny?

No. Are you desperately trying to be an idiot? Or are you just soused
again?

Charlton

 

[Paul E. Schoen]

PES> Yes, I was very confused about what the point was. I have no
PES> idea why the following line would ever need to be parsed in C,
PES> or in any other language:

PES> foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true

Consider a list of CGI form parameters in a GET query string.

Well, I had to look up what a GET query string was. I found a reasonable
explanation at:
http://www.antipope.org/charlie/attic/webbook/ch5perl/perl7.html

Then I searched for what CGI form parameters were. I found:
http://www.perlmeme.org/tutorials/cgi_form.html

Now I am somewhat at a loss as to what created the GET query string in the
first place, and I also see that it seems to use semicolons instead of the
ampersands that are specified in the explanation. But my understanding is
that a query string is usually generated as a result of items a user may
have entered or selected in a blank form, and these items are then
interpreted and converted to HTML so that a new document will be created
according to the request of the user.

So, AIUI, the CGI script only needs to parse the query string and then
create a new HTML according to the parameters which were generated by the
original form, and the script is written specifically for that form, so it
already knows what the variables are, and what the values mean. So the
string could be formatted in any way that the script could understand, and
convert back to appropriate HTML.

I'm also not quite sure why the query string needs to be part of the URL,
although I can see that it identifies how the CGI script should format the
special version of the form as desired by the user. Thus the original URL
is just the blank form and the URL with the query is the modified version
as created by the CGI script. I take it that this exists as a temporary
file on the server which is then read by the browser?

There is probably a very basic level of understanding that I just do not
quite grasp.

Paul

 

[Charlton Wilbur]

PES> There is probably a very basic level of understanding that I
PES> just do not quite grasp.

Yes, I'd say that's a very accurate statement.

Charlton

 

[sln]

In no way, shape or form, is this a problem specification, nor anything
of
any use to anything or anybody, et all.

[snip]

Yes, I was very confused about what the point was. I have no idea why the
following line would ever need to be parsed in C, or in any other language:

foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true
[snip]

And the point of using fewer lines to accomplish the same thing is not very
beneficial if the code is difficult to understand. Delphi (Pascal) does
tend to be rather verbose, and I wish there were constructs like {} rather
than "Begin" and "End", but well-written code with liberal use of
indentation and whitespace make it easy to understand and maintain. "C" has
some operators that make for more compact code, but IMHO at the cost of
readability. Then Perl seems to be at another level of brevity that reminds
me of command line switches as used in MSDOS and even CP/M utilities like
the line editor "ed".

Paul

Ah CP/M, z80(a), Zilog. My first real computer TimexSinclair Z80.
Assembly, my first language. Z80a decompiler, my first program.

In all fairness, I only read the last few posts starting with Dr. Ruud's
apparent solution to what appeared (to him I think) to be a problem statement
by Wilbur guy.

Well, in all fairness to me, as threads fracture, so they become fractured.

-sln

 

[sln]

"PES" == Paul E Schoen <[email protected]> writes:

[snip]
There is probably a very basic level of understanding that I just do not
quite grasp.

Indeed.

You seem to not have a grasp of the rudiments of how the WWW
(ie. HTTP requests and responses) operates.

How it operates is independent of the language you choose to
implement the parts necessary, and hence is not on-topic in
a programming language newsgroup.

Now about ON-TOPIC, I wouldn't go that far Tad. If you take away
applications, programming language newsgroups wouldn't exist.
Larry would be the only poster here, questions and answers.

-sln

 

[sln]

Yes, I'd say that's a very accurate statement.

Charlton

I'm not sure you are qualified to determine accuracy are you fella?

-sln