variable-length strings
Uno
I begin a crosspost herewith that I hope to make relevant to the
newsgroups listed. It will take some time to get to there from here, but
the ambition is to make it relatively lean with the topicality of each
ng addressed and respected. I am OP; if that's a problem for you, I'd
like you to move on graciously.
It begins with perl, which I am currently reading. So that's gonna be
q1). There will be more questions in the same format, and I would like
to make you aware of that as you consider an editorial choice. OP
suggests editorial choices that derive from the questions, that is, are
trimmed with respect to q.
$ pwd
/media/KINGSTON
$ perl marni3.pl
death
$ cat marni3.pl
#!/usr/bin/perl -w
use Net::FTP;
my $domain = 'www.merrillpjensen.com';
my $username = 'u61210220';
my $password = '';
my $file = 'jac1.avi';
$ftp = Net::FTP->new($domain) or die "Can't connect: $@\n";
$ftp->login($username, $password) or die "Couldn't login\n";
$ftp->cwd('/wsb6326330301/resources/') or die "death $@\n";
$ftp->put($file) or die "put failed ", $ftp->message;
$
q1) Why did I die?
I had a very successful day. I could show it, except that I'm unable to
communicate well with the internet. This is usually the case when I try
to extend my ubuntu capability. I have something that hangs that
wouldn't under a more firmly-established identity.
q2) [I imagine that I have a distinct question for each listed ng] In
testing, I've noticed a difference in file sizes between what I upload
with ftp and what I download. The files are 60 megs, conceived by
apple, and I can't show what I'm saying until I get ftp working.
There's no way I can look at these files with a hex editor and my eyes.
Doesn't unix have a built-in way to compare them?
q3)
a) Is there some newsgroup out there that considers web design, and not
the kind where you have to give them money for their opinion. If I paid
$40 for usenet advice, it might be worse than what a hooker on central
might do; it's given by people who want to make $40 on usenet.
alt.web.css.embedded.object.rus ?
q4) and then the good people of c.l.c. It looks like your tone has
come a long way. Down the road I'd like to consider how to pass
information which is perl input to fortran output using the iso c binding.
Cheers,
--
Uno
ccc31807
> q1) Why did I die?
The simplest place to start is with your command line ftp program. If
you can connect and transfer files with your command line ftp, then IN
THEORY you should be able to put the same series of commands in a
batch file (i.e., a Perl script) and run them. If you can do that,
then you have all the functionality you neet./
> q2) [I imagine that I have a distinct question for each listed ng] In
> There's no way I can look at these files with a hex editor and my eyes.
> Doesn't unix have a built-in way to compare them?
On Unix/Linux, use diff. If you are comfortable with vi/vim, it also
has a diff capability.
> q3)
>
> a) Is there some newsgroup out there that considers web design, and not
> the kind where you have to give them money for their opinion. If I paid
> $40 for usenet advice, it might be worse than what a hooker on central
> might do; it's given by people who want to make $40 on usenet.
Sorry, but you need to rephrase your question, as this does not make
sense to me.
> q4) and then the good people of c.l.c. It looks like your tone has
> come a long way. Down the road I'd like to consider how to pass
> information which is perl input to fortran output using the iso c binding.
Data is data. You can use Perl to manipulate and format data. In fact,
PERL (in the opinion of some, anyway) stands for Practical Extraction
and Reporting Language.
CC.
George Mpouras
$ftp = Net::FTP->new($domain, Debug=>1, Passive=>1)
Peter J. Holzer
On 2011-06-01 09:36, Uno <U...@example.invalid> wrote:
> $ perl marni3.pl
> death
> $ cat marni3.pl
> #!/usr/bin/perl -w
> use Net::FTP;
> my $domain = 'www.merrillpjensen.com';
> my $username = 'u61210220';
> my $password = '';
> my $file = 'jac1.avi';
>
>
> $ftp = Net::FTP->new($domain) or die "Can't connect: $@\n";
> $ftp->login($username, $password) or die "Couldn't login\n";
>
> $ftp->cwd('/wsb6326330301/resources/') or die "death $@\n";
> $ftp->put($file) or die "put failed ", $ftp->message;
>
> $
>
> q1) Why did I die?
Simple answer: Because you couldn't change the current working directory
to '/wsb6326330301/resources/'.
As to why that didn't work, the Net::FTP module would tell you if you
asked it. Read the synopsis of perldoc Net::FTP for a few examples on
printing proper error messages.
hp
Peter J. Holzer
On 2011-06-01 09:36, Uno <U...@example.invalid> wrote:
> testing, I've noticed a difference in file sizes between what I upload
> with ftp and what I download. The files are 60 megs, conceived by
> apple, and I can't show what I'm saying until I get ftp working.
>
> There's no way I can look at these files with a hex editor and my eyes.
> Doesn't unix have a built-in way to compare them?
There's cmp, but it only shows you where the first difference is.
There's diff, but it is intended for text files.
You could convert both files with od or hd and diff those. But that
doesn't work well.
I think Emacs has a binary-diff mode, but I'm from the vi fraction.
So, back in the mid 1990's I wrote bdiff (binary diff):
http://www.hjp.at/programs/bdiff/
I guess I should dust it off, write a man-page and try to get it added
to some linux distribution. But I very rarely need it myself.
hp
Uno
> On Jun 1, 5:36 am, Uno<U...@example.invalid> wrote:
>> q1) Why did I die?
>
> The simplest place to start is with your command line ftp program. If
> you can connect and transfer files with your command line ftp, then IN
> THEORY you should be able to put the same series of commands in a
> batch file (i.e., a Perl script) and run them. If you can do that,
> then you have all the functionality you neet./
I needed a fresh day and fresh eyes, and t set Debug=> 2 to see that the
wsb "web site builder" number was wrong. That's a separate directory
that my host uses for when they build the website. I want to adios this
thing, so I called them, and they have you change an administrative
setting so that a browser will be directed to the index.html in the root
menu as opposed to in the wsb folder.
So now this /wsb.../ thing is a relic for me to play with and destroy.
Why didn't this work:
[sorry can only paste as quotation:]
> $ perl marni5.pl
> Net::FTP>>> Net::FTP(2.77)
> Net::FTP>>> Exporter(5.63)
> Net::FTP>>> Net::Cmd(2.29)
> Net::FTP>>> IO::Socket::INET(1.31)
> Net::FTP>>> IO::Socket(1.31)
> Net::FTP>>> IO::Handle(1.28)
> Net::FTP=GLOB(0xa07a7d8)<<< 220 FTP Server ready.
> Net::FTP=GLOB(0xa07a7d8)>>> USER u61210220
> Net::FTP=GLOB(0xa07a7d8)<<< 331 Password required for u61210220
> Net::FTP=GLOB(0xa07a7d8)>>> PASS ....
> Net::FTP=GLOB(0xa07a7d8)<<< 230 User u61210220 logged in
> Net::FTP=GLOB(0xa07a7d8)>>> RMD /wsb6121022001/
> Net::FTP=GLOB(0xa07a7d8)<<< 550 /wsb6121022001/: Directory not empty
> Net::FTP=GLOB(0xa07a7d8)>>> PORT 192,168,0,64,142,193
> Net::FTP=GLOB(0xa07a7d8)<<< 200 PORT command successful
> Net::FTP=GLOB(0xa07a7d8)>>> NLST /wsb6121022001/
> Net::FTP=GLOB(0xa07a7d8)<<< 150 Opening ASCII mode data connection for file list
> Net::FTP=GLOB(0xa07a7d8)<<< 226 Transfer complete
> Net::FTP=GLOB(0xa07a7d8)>>> DELE /wsb6121022001/.
> Net::FTP=GLOB(0xa07a7d8)<<< 550 /wsb6121022001/.: Is a directory
> Net::FTP=GLOB(0xa07a7d8)>>> RMD /wsb6121022001/.
> Net::FTP=GLOB(0xa07a7d8)<<< 550 /wsb6121022001/.: Directory not empty
> Net::FTP=GLOB(0xa07a7d8)>>> PORT 192,168,0,64,186,213
> Net::FTP=GLOB(0xa07a7d8)<<< 200 PORT command successful
> Net::FTP=GLOB(0xa07a7d8)>>> NLST /wsb6121022001/.
> Net::FTP=GLOB(0xa07a7d8)<<< 150 Opening ASCII mode data connection for file list
> Net::FTP=GLOB(0xa07a7d8)<<< 226 Transfer complete
...
it just keeps on telling me Directory not empty
> ^C
> $ cat marni5.pl
> #!/usr/bin/perl -w
> use Net::FTP;
> my $domain = 'www.merrillpjensen.com';
> my $username = 'u61210220';
> my $password = '';
>
> $ftp = Net::FTP->new($domain, Debug => 2) or die "Can't connect: $@\n";
> $ftp->login($username, $password) or die "Couldn't login\n";
>
> my $recurse = 1;
> $ftp->rmdir('/wsb6121022001/', $recurse);
> #$ftp->cwd('/wsb6121022001/') or die "death $@\n";
>
> my @file = $ftp->ls();
>
> foreach $file (@file){
> print "$file\n";
> }
> $
Cpan says that RECURSE has to be true, and I thought a good guess for
"true" in a syntax that is a child of C would be one.
>
>> q2) [I imagine that I have a distinct question for each listed ng] In
>> There's no way I can look at these files with a hex editor and my eyes.
>> Doesn't unix have a built-in way to compare them?
>
> On Unix/Linux, use diff. If you are comfortable with vi/vim, it also
> has a diff capability.
Thx, ccc, I'll do that. Here's what's vexing me right now.
http://www.merrillpjensen.com/images/jac1.bmp
The only difference between these files, is that the smaller one went on
a round on the internet. It was sent up like this:
> #!/usr/bin/perl -w
> use strict;
> use Net::FTP;
> my $domain = 'www.merrillpjensen.com';
> my $username = 'u61210220';
> my $password = '';
> my $file = 'jac1.bmp';
> my $dir = '/images/';
>
> my $ftp = Net::FTP->new($domain, Debug =>2) or die "Can't connect: $@\n";
> $ftp->login($username, $password) or die "Couldn't login\n";
> $ftp->mkdir($dir) or die "death: $@\n";
> $ftp->cwd($dir) or die "death: $@\n";
> $ftp->put($file) or die "put failed ", $ftp->message;
And downloaded using google chrome. Is this typical, because if my
experience is, then I don't really see how any large file gets
transferred faithfully.
Gotta go pull down some legal tender. Adios.
--
Uno
Uno
> On 2011-06-04 04:58, Uno<U...@example.invalid> wrote:
>> On 06/02/2011 07:44 AM, Peter J. Holzer wrote:
>>> So, back in the mid 1990's I wrote bdiff (binary diff):
>>> http://www.hjp.at/programs/bdiff/
>>>
>>> I guess I should dust it off, write a man-page and try to get it added
>>> to some linux distribution. But I very rarely need it myself.
>> So I downloaded your software, extracted it on a thumbdrive, compiled
>> it, told ubuntu to run it, and it told me I don't have permission.
>>
>> $ sudo chmod 777 bdiff
>> $ ls -l
>>
>> -rw-r--r-- 1 dan dan 12414 2011-06-02 16:29 bdiff
>>
>> That was my last try with that executable. So I tried it again.
>>
>> $ pwd
>> /media/KINGSTON/bdiff-1.0
> ^^^^^^^^^^^^^^^^
>
> What kind of file system is this and how is it mounted?
>
>> $ cc -Wall -Wextra bdiff.c -o bdiff2
>> bdiff.c: In function ‘readfile’:
>> bdiff.c:98: warning: comparison between signed and unsigned integer
>> expressions
>
> The warnings are harmless, AFAICS, and partially misleading (comparison
> between size_t and -1 is well-defined as long as sizeof(size_t)>=
> sizeof(int), which is pretty much guaranteed).
>
> hp
I want to pursue this on the C side for a bit. [x-posted to clc]
$ pwd
/home/dan/source/bdiff-1.0
$ cc -Wall -Wextra cmp1.c -o cmp
cmp1.c: In function ‘main’:
cmp1.c:12: warning: comparison is always true due to limited range of
data type
cmp1.c:17: warning: implicit declaration of function ‘close’
cmp1.c:18: error: expected declaration or statement at end of input
$ cat cmp1.c
#include <stdio.h>
int main(void)
{
unsigned char c;
long counter = 0;
FILE *fp;
fp=fopen("shoulder.wmv", "rb+");
while ((c = fgetc(fp)) != EOF)
{
counter++;
}
printf("Counter reached %ld\n", counter);
close (fp);
return 0;
// cc -Wall -Wextra cmp1.c -o cmp
$
What obvious thing am I missing here?
--
Uno
Ian Collins
>
> I want to pursue this on the C side for a bit. [x-posted to clc]
>
> $ pwd
> /home/dan/source/bdiff-1.0
> $ cc -Wall -Wextra cmp1.c -o cmp
> cmp1.c: In function ‘main’:
> cmp1.c:12: warning: comparison is always true due to limited range of
> data type
> cmp1.c:17: warning: implicit declaration of function ‘close’
> cmp1.c:18: error: expected declaration or statement at end of input
> $ cat cmp1.c
>
> #include<stdio.h>
>
> int main(void)
> {
> unsigned char c;
> long counter = 0;
> FILE *fp;
>
> fp=fopen("shoulder.wmv", "rb+");
>
> while ((c = fgetc(fp)) != EOF)
I'm guessing this is line 12. fgetc returns an int. EOF is an integer
constant.
> {
> counter++;
> }
> printf("Counter reached %ld\n", counter);
> close (fp);
You are missing <unistd.h>. If you had included it, your compile would
have failed. close works with a file descriptor, not a FILE*.
> return 0;
Missing } ?
--
Ian Collins
Uno
Thx, Ian.
$ cc -Wall -Wextra cmp2.c -o cmp
$ ./cmp
Counter reached 19573712
$ ls -l
...
-rw-r--r-- 1 dan dan 19573712 2011-06-05 17:32 shoulder.wmv
$ cat cmp2.c
#include <stdio.h>
int main(void)
{
int c;
long counter = 0;
FILE *fp;
fp=fopen("shoulder.wmv", "rb+");
while ((c = fgetc(fp)) != EOF)
{
counter++;
}
printf("Counter reached %ld\n", counter);
fclose (fp);
return 0;
}
// cc -Wall -Wextra cmp2.c -o cmp
$
I guess I thought with counter starting at zero that the numbers
wouldn't agree exactly, but they do.
It's a weird night here in abq; I'm gonna go out and howl at the orange
moon.
--
Uno
Uno
I'm stuck again, so that's the night. I don't see why this wouldn't
traverse both files for the length of the shorter one:
$ cc -Wall -Wextra cmp4.c -o cmp
cmp4.c: In function ‘main’:
cmp4.c:12: error: expected statement before ‘)’ token
$ cat cmp4.c
#include <stdio.h>
int main(void)
{
int c, d;
long counter = 0;
FILE *fp, *fq;
fp=fopen("shoulder.wmv", "rb+");
fq=fopen("downloaded1.wmv", "rb+");
while (((c = fgetc(fp)) != EOF) || (d = fgetc(fq)) != EOF))
{
counter++;
if (counter == 10000)
{
printf("int is %d\n", c);
}
if ( c != d)
{
printf("Ungleich: %ld\n", counter);
}
}
printf("Counter reached %ld\n", counter);
fclose (fp);
return 0;
}
// cc -Wall -Wextra cmp4.c -o cmp
$
My parens are probably mismatched by now, but I don't make one statement
on that line; I think I make two.
--
Uno
Janis Papanagnou
Here you seem to be asking why your algorithm doesn't work,
but below you show us an apparent compiler syntax error;
your parenthesis are not balanced in line 12.
>
> $ cc -Wall -Wextra cmp4.c -o cmp
> cmp4.c: In function ‘main’:
> cmp4.c:12: error: expected statement before ‘)’ token
> $ cat cmp4.c
> #include <stdio.h>
>
> int main(void)
> {
> int c, d;
> long counter = 0;
> FILE *fp, *fq;
>
> fp=fopen("shoulder.wmv", "rb+");
> fq=fopen("downloaded1.wmv", "rb+");
>
> while (((c = fgetc(fp)) != EOF) || (d = fgetc(fq)) != EOF))
while ( (c = fgetc(fp)) != EOF
|| (d = fgetc(fq)) != EOF )
> {
> counter++;
> if (counter == 10000)
> {
> printf("int is %d\n", c);
> }
>
> if ( c != d)
> {
> printf("Ungleich: %ld\n", counter);
> }
> }
> printf("Counter reached %ld\n", counter);
> fclose (fp);
> return 0;
> }
> // cc -Wall -Wextra cmp4.c -o cmp
> $
>
> My parens are probably mismatched by now, but I don't make one statement
> on that line; I think I make two.
The compiler doesn't know what your intention was; it's irrelevant
how many statements you have. Fix your syntax.
BTW, why are you posting this to comp.unix.shell?
Janis
Eric Sosman
>
> $ pwd
> /home/dan/source/bdiff-1.0
> $ cc -Wall -Wextra cmp1.c -o cmp
> cmp1.c: In function ‘main’:
> cmp1.c:12: warning: comparison is always true due to limited range of
> data type
> cmp1.c:17: warning: implicit declaration of function ‘close’
> cmp1.c:18: error: expected declaration or statement at end of input
> $ cat cmp1.c
>
> #include <stdio.h>
>
> int main(void)
> {
> unsigned char c;
> long counter = 0;
> FILE *fp;
>
> fp=fopen("shoulder.wmv", "rb+");
>
> while ((c = fgetc(fp)) != EOF)
> {
> counter++;
> }
> printf("Counter reached %ld\n", counter);
> close (fp);
> return 0;
> // cc -Wall -Wextra cmp1.c -o cmp
> $
>
> What obvious thing am I missing here?
First, that an `unsigned char', necessarily non-negative,
cannot be equal to the negative value EOF. (Let's ignore
exotic systems where sizeof(int)==1, okay?)
Second, that fclose() is spelled with an initial "f". By
writing it as close(), you've f-ed up.
Third, that some C delimiters are used in matching pairs.
Just as each ( needs a matching ), so each { needs a matching }.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Uno
> The compiler doesn't know what your intention was; it's irrelevant
> how many statements you have. Fix your syntax.
Thx, janis. I have it syntactical now, but the behavior has a ways to
come. Why does my program think that the first byte's are differing,
while the unix command thinks that only occurs much later:
$ cc -Wall -Wextra cmp4.c -o cmp
$ ./cmp
Ungleich: 1
c and d are 48 and 134514059
Counter reached 1
$ cmp shoulder.wmv downloaded1.wmv
shoulder.wmv downloaded1.wmv differ: byte 196502, line 1409
$ cat cmp4.c
#include <stdio.h>
int main(void)
{
int c, d;
long counter = 0;
FILE *fp, *fq;
fp = fopen("shoulder.wmv", "rb+");
fq = fopen("downloaded1.wmv", "rb+");
while (((c = fgetc(fp)) != EOF) || ((d = fgetc(fq)) != EOF)) {
counter++;
if (counter == 10000) {
printf("int is %d\n", c);
}
if (c != d) {
printf("Ungleich: %ld\n", counter);
printf("c and d are %d and %d\n", c, d);
break;
}
}
printf("Counter reached %ld\n", counter);
fclose(fp);
return 0;
}
// cc -Wall -Wextra cmp4.c -o cmp
$
>
> BTW, why are you posting this to comp.unix.shell?
>
*nix is my platform, and whenever I'm cooking up a project with a
programming language, I hit at least one big gotcha with the OS. Also,
I'm trying to imitate the functionality of cmp somewhat.
Are you suggesting that another unix group might be more appropriate?
--
Uno
Uno
> On 6/8/2011 11:59 PM, Uno wrote:
>> What obvious thing am I missing here?
>
> First, that an `unsigned char', necessarily non-negative,
> cannot be equal to the negative value EOF. (Let's ignore
> exotic systems where sizeof(int)==1, okay?)
Right. I wish I could say this was the only time I'd forgotten that. I
could blame Heathfield for making me think that unsigned chars were what
I wanted to deal with binary data, but at some point, one owns his own
misperceptions.
>
> Second, that fclose() is spelled with an initial "f". By
> writing it as close(), you've f-ed up.
>
> Third, that some C delimiters are used in matching pairs.
> Just as each ( needs a matching ), so each { needs a matching }.
>
[OT]
Is that forest fire gonna affect AZ population centers? It's turning
into a bummer for NM. How can it still be zero percent contained?
--
Uno
James Waldby
...
> Why does my program think that the first byte's are differing,
> while the unix command thinks that only occurs much later:
>
> $ cc -Wall -Wextra cmp4.c -o cmp
> $ ./cmp
> Ungleich: 1
> c and d are 48 and 134514059
By C evaluation rules, both || and && will "shortcut" when
not all terms need to be evaluated. For example, in
expression (1 || xyz), xyz will never be evaluated.
> while (((c = fgetc(fp)) != EOF) || ((d = fgetc(fq)) != EOF)) {
...
--
jiw
Angel
> On 06/09/2011 03:10 AM, Janis Papanagnou wrote:
>
>> The compiler doesn't know what your intention was; it's irrelevant
>> how many statements you have. Fix your syntax.
>
> Thx, janis. I have it syntactical now, but the behavior has a ways to
> come. Why does my program think that the first byte's are differing,
> while the unix command thinks that only occurs much later:
Problem is here:
> while (((c = fgetc(fp)) != EOF) || ((d = fgetc(fq)) != EOF)) {
If the left operand of the || operator evaluates to true, the right
operand is not evaluated, because the expression is already known to be
true as a whole.
In other words, as long as the value assigned to c != 0, d is never read,
and thus d is used uninitialized in the rest of the code.
--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c
Ben Pfaff
> while (((c = fgetc(fp)) != EOF) || ((d = fgetc(fq)) != EOF)) {
You want to read one byte from each file on every loop iteration,
but this will only read from fq if the read from fp fails.
Try something more like this:
for (;;) {
c = fgetc(fp);
d = fgetc(fq);
if (c == EOF || d == EOF)
break;
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman
Keith Thompson
> On 06/09/2011 05:13 AM, Eric Sosman wrote:
>> On 6/8/2011 11:59 PM, Uno wrote:
>
>>> What obvious thing am I missing here?
>>
>> First, that an `unsigned char', necessarily non-negative,
>> cannot be equal to the negative value EOF. (Let's ignore
>> exotic systems where sizeof(int)==1, okay?)
>
> Right. I wish I could say this was the only time I'd forgotten that. I
> could blame Heathfield for making me think that unsigned chars were what
> I wanted to deal with binary data, but at some point, one owns his own
> misperceptions.
unsigned chars *are* what you should use to deal with binary data.
Your problem was that you were assigning the result of fgetc()
to an unsigned char object. Using a signed char or a plain char
would also have been wrong. fgetc() returns an int. Read your
documentation to see how that int value is generated.
I'm dropping comp.unix.shell from the cross-post.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Uno
> Uno<U...@example.invalid> writes:
>
>> while (((c = fgetc(fp)) != EOF) || ((d = fgetc(fq)) != EOF)) {
>
> You want to read one byte from each file on every loop iteration,
> but this will only read from fq if the read from fp fails.
>
> Try something more like this:
>
> for (;;) {
> c = fgetc(fp);
> d = fgetc(fq);
> if (c == EOF || d == EOF)
> break;
Thx Ben. I knew that the usual idiom wouldn't work for files of
different sizes, but with the short-circuiting, it didn't work at all.
$ cc -Wall -Wextra cmp5.c -o cmp
$ ./cmp
counter, c, and d are: 196500 236 236
counter, c, and d are: 196501 108 108
counter, c, and d are: 196502 13 10
counter, c, and d are: 196503 10 122
counter, c, and d are: 196504 122 185
counter, c, and d are: 196505 185 113
counter, c, and d are: 196506 113 83
counter, c, and d are: 196507 83 106
counter, c, and d are: 196508 106 149
counter, c, and d are: 196509 149 174
counter, c, and d are: 196510 174 77
Counter reached 19573258
$ cat cmp5.c
#include <stdio.h>
int main(void)
{
int c, d;
long counter = 0;
FILE *fp, *fq;
fp = fopen("shoulder.wmv", "rb+");
fq = fopen("downloaded1.wmv", "rb+");
for (;;) {
c = fgetc(fp);
d = fgetc(fq);
if (c == EOF || d == EOF)
break;
counter++;
if ((counter >= 196500) && (counter <= 196510)) {
printf("counter, c, and d are: %ld %d %d\n", counter, c, d);
}
}
printf("Counter reached %ld\n", counter);
fclose(fp);
return 0;
}
// cc -Wall -Wextra cmp5.c -o cmp
$
I'm trying to get my head around what Alan Curry wrote about this:
"Octal 15 (ASCII CR) inserted before octal 12 (ASCII LF). Classical
text-mode FTP corruption."
Can someone say a few more words about what ftp may have done here?
--
Uno
Uno
> On 2011-06-09, Uno<U...@example.invalid> wrote:
>> On 06/09/2011 03:10 AM, Janis Papanagnou wrote:
>>
>>> The compiler doesn't know what your intention was; it's irrelevant
>>> how many statements you have. Fix your syntax.
>>
>> Thx, janis. I have it syntactical now, but the behavior has a ways to
>> come. Why does my program think that the first byte's are differing,
>> while the unix command thinks that only occurs much later:
>
> Problem is here:
>
>> while (((c = fgetc(fp)) != EOF) || ((d = fgetc(fq)) != EOF)) {
>
> If the left operand of the || operator evaluates to true, the right
> operand is not evaluated, because the expression is already known to be
> true as a whole.
>
> In other words, as long as the value assigned to c != 0, d is never read,
> and thus d is used uninitialized in the rest of the code.
>
>
Thx, james and angel. Somehow, my only reference handy is a german
language K&R2, and I don't see a mention of the short-circuiting of
ODER, although, of course, it is well-known (by you maybe more than me).
Cheers,
--
Uno
Ike Naar
Why are you using ``||'' here? Wouldn't ``&&'' make more sense?
Alan Curry
> fclose(fp);
> return 0;
>}
>
>// cc -Wall -Wextra cmp5.c -o cmp
>$
Right here, where the C code ended... would have been a good time to start a
new post on another group.
>
>I'm trying to get my head around what Alan Curry wrote about this:
>
>"Octal 15 (ASCII CR) inserted before octal 12 (ASCII LF). Classical
>text-mode FTP corruption."
>
>Can someone say a few more words about what ftp may have done here?
FTP was invented when dinosaurs roamed the Internet. The dinosaurs growled,
roared, and screeched ASCII, which was presented to the users on hardcopy
terminals - typewriters, basically.
[If you're not old enough to have ever seen a typewriter, google up an image
of one now, or preferably a video of one in use.]
When text is written on a typewriter, there are 2 actions required at the end
of a line before starting the next line: move the carriage (that's the
printing thingy) to the left margin, and scroll the paper up.
[You may now ponder how the connection is formed between the ancient and
modern meanings of the word "scroll"]
ASCII was partially designed as a typewriter control language, and 2 of its
control codes are used to instruct the typewriter to perform its end-of-line
actions:
Character number 13 is "Carriage Return" (CR) - move the printing thingy to
the left.
Character number 10 is "Linefeed" (LF) - feed one more line of paper into the
machine.
The dinosaurs were a rowdy bunch, and they fought over how to properly store
text on non-typewriter-like media (like tapes and disks), but they were all
able to understand the typewriter-like ASCII-with-CRLF format. It was the
universal text representation. And it was incorporated into FTP as the
standard format for transmission of text files.
A bit later, UNIX was created. It was like a small mammal, hiding
underground, barely noticed and definitely not respected by the dinosaurs.
And the UNIX guys observed that text files on disk were becoming more
numerous than text printouts. And they said that soon typewriters as a user
interface would be obsolete, replaced by CRTs. and that eventually people
would send text to each other without even using paper.
In such a future it would make no sense to keep using that old pair of
typewriter commands to separate lines of text. It would be much better to
take "end this line, begin next line" as a single logical operation and allow
it to be represented by a single control code. They called this new control
code "NEWLINE". It was a revolutionary idea.
And the dinosaurs ignored it, and kept making up Internet protocols with
mandatory typewriter-style line endings.
When later generations of UNIX got big enough to climb out of their
underground tunnels and talk to the Internet, they had a problem: all of
their private text files and utilities were designed around the NEWLINE idea,
but all of the Internet protocols, including FTP, required CRLF. FTP clients
and servers on UNIX have to perform translation. When sending a file, they
transform it from NEWLINE format to CRLF format. When receiving it, they do
the opposite.
When sending a text file, UNIX FTP changes the file into the dinosaur
typewriter format by inserting a CR (13) before every NEWLINE (10). When
receiving a text, it changes each CRLF pair into NEWLINE. Note that it
doesn't have to actually look for CRLF pairs. It can just delete all the CRs,
since LF and NEWLINE have the same numerical value (10) and a CR that is not
part of a CRLF pair is not allowed.
When those transformations are applied to things that aren't actually text
files, the result can be a disaster, because bytes with value 13 can
disappear, or can be added before bytes with value 10. The transformation
isn't reversible when the input contains unpaired CR or LF bytes.
So your file got corrupted because you used ASCII mode FTP and you got caught
speaking ungrammatical dinosaur typewriter Esperanto.
Use binary mode. (Technically, in the language of FTP, "TYPE IMAGE", but most
clients call it "binary mode")
And yeah, you could have just googled "FTP binary" but I felt like writing a
story about dinosaurs anyway so here you go.
--
Alan Curry
Uno
> Uno<U...@example.invalid> writes:
>> On 06/09/2011 05:13 AM, Eric Sosman wrote:
>>> On 6/8/2011 11:59 PM, Uno wrote:
>>
>>>> What obvious thing am I missing here?
>>>
>>> First, that an `unsigned char', necessarily non-negative,
>>> cannot be equal to the negative value EOF. (Let's ignore
>>> exotic systems where sizeof(int)==1, okay?)
>>
>> Right. I wish I could say this was the only time I'd forgotten that. I
>> could blame Heathfield for making me think that unsigned chars were what
>> I wanted to deal with binary data, but at some point, one owns his own
>> misperceptions.
>
> unsigned chars *are* what you should use to deal with binary data.
>
> Your problem was that you were assigning the result of fgetc()
> to an unsigned char object. Using a signed char or a plain char
> would also have been wrong. fgetc() returns an int. Read your
> documentation to see how that int value is generated.
>
> I'm dropping comp.unix.shell from the cross-post.
>
Ok. So we have
int c;
unsigned char s;
My first guess on how to get this transferred faithfully would be
for (;;){
s = c;
My second guess is
for (;;){
s = (unsigned char)c;
, but that looks rather heavy-handed for something that wasn't broken
when we started.
I don't have an appropriate reference for fgetc and dinkumware has been
down.
What would I need to install to be able to man fgetc?
--
Uno
Morris Keesan
> I don't have an appropriate reference for fgetc and dinkumware has been
> down.
>
> What would I need to install to be able to man fgetc?
Try
http://pubs.opengroup.org/onlinepubs/009695399/functions/fgetc.html
--
Morris Keesan -- mke...@post.harvard.edu
Uno
> On Fri, 10 Jun 2011 00:11:37 -0400, Uno <merril...@q.com> wrote:
>
>
>> I don't have an appropriate reference for fgetc and dinkumware has
>> been down.
>>
>> What would I need to install to be able to man fgetc?
>
> Try
> http://pubs.opengroup.org/onlinepubs/009695399/functions/fgetc.html
>
Thx, Morris.
If the end-of-file indicator for the input stream pointed to by stream
is not set and a next byte is present, the fgetc() function shall obtain
the next byte as an unsigned char converted to an int, from the input
stream pointed to by stream, and advance the associated file position
indicator for the stream (if defined). Since fgetc() operates on bytes,
reading a character consisting of multiple bytes (or "a multi-byte
character") may require multiple calls to fgetc().
What is the relationship between unsigned chars and ints? Both unsigned
and signed chars are subsets of ints, but why are unsigned chars the
representation of choice with binary data?
--
Uno
Angel
>
> What is the relationship between unsigned chars and ints? Both unsigned
> and signed chars are subsets of ints, but why are unsigned chars the
> representation of choice with binary data?
Because with signed char, there may be trap representations (binary
numbers that are not a valid signed char) in arbitrary binary data.
Keith Thompson
[...]
> What is the relationship between unsigned chars and ints? Both unsigned
> and signed chars are subsets of ints, but why are unsigned chars the
> representation of choice with binary data?
Because if you have a byte whose content is all-bits-one, it generally
makes more sense to think of it as 255 or 0xff than as -1.
If your binary data actually consists of signed bytes, then by all means
treat it as signed bytes, but that's fairly unusual.
Shao Miller
> On 2011-06-12, Uno<U...@example.invalid> wrote:
>>
>> What is the relationship between unsigned chars and ints? Both unsigned
>> and signed chars are subsets of ints, but why are unsigned chars the
>> representation of choice with binary data?
>
> Because with signed char, there may be trap representations (binary
> numbers that are not a valid signed char) in arbitrary binary data.
>
Is that consistent with 6.2.6.1p5? "Character type," below.
"Certain object representations need not represent a value of the
object type. If the stored value of an object has such a representation
and is read by an lvalue expression that does not have character type,
the behavior is undefined. If such a representation is produced by a
side effect that modifies all or any part of the object by an lvalue
expression that does not have character type, the behavior is undefined.
Such a representation is called a /trap representation/."
Shao Miller
>
> What is the relationship between unsigned chars and ints? Both unsigned
> and signed chars are subsets of ints, but why are unsigned chars the
> representation of choice with binary data?
'unsigned char' has 'CHAR_BIT' bits. 'sizeof (unsigned char) == 1'.
'unsigned char' has no padding bits and no sign bit. Unsigned integer
types do not overflow from arithmetic operations. Because of these
guarantees, you can manipulate (unless 'const'-qualified) or inspect
_all_ the bits of _any_ object if you access the bytes of that object
using an lvalue with type 'unsigned char'.
On aspect of the relationship between 'unsigned char' and 'int' or
'unsigned int' is that the rank of 'int' and 'unsigned int' is greater
than the rank of 'unsigned char'. Another is that the range of values
for 'unsigned char' is a subset of the range of values for 'unsigned int'.
Robert Bonomi
>On 06/08/2011 10:20 PM, Uno wrote:
>>
>> It's a weird night here in abq; I'm gonna go out and howl at the orange
>> moon.
Did you hear about the werewolf in San Francisco? down at Fisherman's Wharf,
he faced away from the waterfront, and dropped trou.
As one local put it -- "Silly mixed-up werewolf, mooning at the bay!"
*groan*
>I'm stuck again, so that's the night. I don't see why this wouldn't
>traverse both files for the length of the shorter one:
THIMK!!! what happens on the *OR* condition when _one_ test becomes FALSE??
>$ cc -Wall -Wextra cmp4.c -o cmp
>cmp4.c: In function ‘main’:
>cmp4.c:12: error: expected statement before ‘)’ token
[[ sneck ]]
[[ cmp4.c line 12 follows: ]]
>
> while (((c = fgetc(fp)) != EOF) || (d = fgetc(fq)) != EOF))
>
>My parens are probably mismatched by now, but I don't make one statement
>on that line; I think I make two.
*BINGO* count the parens on the the 'while' line. more ')', than '('.
>--
>Uno
blmblm.m...@gmail.com
Alan Curry <pac...@kosh.dhis.org> wrote:
> In article <95crfq...@mid.individual.net>, Uno <U...@example.invalid> wrote:
[ snip ]
> FTP was invented when dinosaurs roamed the Internet. The dinosaurs growled,
> roared, and screeched ASCII, which was presented to the users on hardcopy
> terminals - typewriters, basically.
That may be true of the dinosaurs that wanted to use this newfangled
file transfer protocol, but some of them (I'm thinking of the ones
made by IBM) mostly used another format, EBCDIC, for representing
character data. Just sayin' (after a rather long delay, for which
I apologize).
> [If you're not old enough to have ever seen a typewriter, google up an image
> of one now, or preferably a video of one in use.]
Good heavens -- are they really people who have never encountered a
typewriter at all? cue chorus of "I feel old", maybe ....
[ snip ]
> The dinosaurs were a rowdy bunch, and they fought over how to properly store
> text on non-typewriter-like media (like tapes and disks), but they were all
> able to understand the typewriter-like ASCII-with-CRLF format. It was the
> universal text representation. And it was incorporated into FTP as the
> standard format for transmission of text files.
I just made a quick attempt to confirm my recollections about
whether the IBM 360/370 architecture included support for ASCII,
and -- it's kind of interesting that the Wikipedia articles say
that the 360 architecture included some features intended to
support ASCII (which had not been finalized), but that these were
not used, or not used widely, and the 370 architecture dropped at
least some of them. I wonder whether there was some consternation
when it became desirable to support FTP, it being ASCII-based.
(I'll leave the rest of this in because it's kind of charming.)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
Robert Wessel
<blmblm.m...@gmail.com> wrote:
>In article <isrgpj$4qq$1...@speranza.aioe.org>,
>Alan Curry <pac...@kosh.dhis.org> wrote:
>
>> The dinosaurs were a rowdy bunch, and they fought over how to properly store
>> text on non-typewriter-like media (like tapes and disks), but they were all
>> able to understand the typewriter-like ASCII-with-CRLF format. It was the
>> universal text representation. And it was incorporated into FTP as the
>> standard format for transmission of text files.
>
>I just made a quick attempt to confirm my recollections about
>whether the IBM 360/370 architecture included support for ASCII,
>and -- it's kind of interesting that the Wikipedia articles say
>that the 360 architecture included some features intended to
>support ASCII (which had not been finalized), but that these were
>not used, or not used widely, and the 370 architecture dropped at
>least some of them. I wonder whether there was some consternation
>when it became desirable to support FTP, it being ASCII-based.
S/360 included a mode bit that altered the behavior of a handful of
instructions that were sensitive to the character set. This was mostly
the decimal instructions which encoded the sign in a nibble of the
least significant byte. For example, in unpacked ("display") form,
the decimal digits were 0xf0-0xf9 in EBCDIC. Thus +123 could be
encoded as 0xf1, 0xf2, 0xf3. A -123 would be encoded 0xf1, xf2, 0xd3.
(Several other values were valid for the sign as well.) So obviously
the instructions that converted between unpacked to packed format were
sensitive to the character set.
In any event, it was a modest behavior change to a few instructions.
And ASCII wasn't really cooked by the time IBM started development of
the OS's, so they ended up sticking with EBCDIC.
That mode bit was reused to enable "Extended Control" mode on the
S/370, which instead changed to format of the PSW and a few other
things (like some of the fixed location in low-core), that was a
prerequisite to enabling virtual memory. So ASCII mode went entirely
away with the S/370.
In the last ~15 years the ISA has grown a number of instructions
designed to ease the processing of ASCII data. Unicode too, as well
as instructions for converting to/from little-endian, and things like
C-style strings.
Stephen Sprunk
> In article <isrgpj$4qq$1...@speranza.aioe.org>,
> Alan Curry <pac...@kosh.dhis.org> wrote:
>> [If you're not old enough to have ever seen a typewriter, google up
>> an image of one now, or preferably a video of one in use.]
>
> Good heavens -- are they really people who have never encountered a
> typewriter at all? cue chorus of "I feel old", maybe ....
I'm in my early 30s, and the only _mechanical_ typewriter I've seen was
an antique originally owned by my grandfather, which my parents used in
college (long before I was born) and kept in storage for sentimental
reasons. I saw a few electronic typewriters in school, but they had all
disappeared by the time I graduated, and I can't recall having seen any
since then; kids just a few years younger than I likely wouldn't
remember them at all.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
blmblm.m...@gmail.com
Thanks for filling in some of the details! That all sounds pretty
consistent with what the Wikipedia articles say, for what that's
worth. Interesting stuff -- though possibly more so to those of who
actually remember those days.
blmblm.m...@gmail.com
Stephen Sprunk <ste...@sprunk.org> wrote:
> On 20-Jun-11 14:14, blm...@myrealbox.com wrote:
> > In article <isrgpj$4qq$1...@speranza.aioe.org>,
> > Alan Curry <pac...@kosh.dhis.org> wrote:
> >> [If you're not old enough to have ever seen a typewriter, google up
> >> an image of one now, or preferably a video of one in use.]
> >
> > Good heavens -- are they really people who have never encountered a
> > typewriter at all? cue chorus of "I feel old", maybe ....
>
> I'm in my early 30s, and the only _mechanical_ typewriter I've seen was
> an antique originally owned by my grandfather, which my parents used in
> college (long before I was born) and kept in storage for sentimental
> reasons. I saw a few electronic typewriters in school, but they had all
> disappeared by the time I graduated, and I can't recall having seen any
> since then; kids just a few years younger than I likely wouldn't
> remember them at all.
Probably typical .... At my CPOE the support staff say they still
want one typewriter, since it's the best tool for one or a few
form-filling-out jobs. I'd have thought maybe this would be true
at many offices, but maybe we're atypical!
Ian Collins
These days people prefer to mess around for hours getting all the text
correctly lined up in their word processor. It's called progress :)
--
Ian Collins
Joe Wright
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
Robert Wessel
FWIW, the following is the sum total impact of ASCII mode on S/360. In
ASCII mode:
- Several instructions would accept the ASCII numeric zone value (0x3)
as an alternate positive sign on input (in EBCDIC mode, the 0xf was
accepted instead). This included most of the instructions that
accepted packed decimal fields as input (AP, CP, CVB, DP, ED, EDMK,
MP, SP, ZAP - add, compare, convert-to-binary, divide, edit,
edit-and-mark, multiply, subtract, zero-and-add). UNPK (unpack), the
other instruction with packed input, just moved the sign nibble
around without regard for its value.
- All instructions except PACK that output packed values generated the
preferred signs (0xc, 0xd - +/-) in both modes. That includes AP, CVD
(convert-to-decimal), DP, MP, SP and ZAP. (So no impact.)
- PACK just moved signs and digits around without regard to their
content. (Again, no differences.)
- The three instructions that generated zoned (display) output (UNPK,
ED, EDMK), inserted the character-set specific zone as specified by
the mode bit.
Eric Sosman
> [...]
> I'm in my early 30s, and the only _mechanical_ typewriter I've seen was
> an antique originally owned by my grandfather, which my parents used in
> college (long before I was born) and kept in storage for sentimental
> reasons. I saw a few electronic typewriters in school, but they had all
> disappeared by the time I graduated, and I can't recall having seen any
> since then; kids just a few years younger than I likely wouldn't
> remember them at all.
Kids a few years younger still wouldn't even notice the
misuse of the nominative case.
--
Eric Sosman
eso...@ieee-dot-org.invalid
superpollo
> In article <itq41h$nih$1...@dont-email.me>,
> Stephen Sprunk <ste...@sprunk.org> wrote:
>> On 20-Jun-11 14:14, blm...@myrealbox.com wrote:
>>> In article <isrgpj$4qq$1...@speranza.aioe.org>,
>>> Alan Curry <pac...@kosh.dhis.org> wrote:
>>>> [If you're not old enough to have ever seen a typewriter, google up
>>>> an image of one now, or preferably a video of one in use.]
>>> Good heavens -- are they really people who have never encountered a
>>> typewriter at all? cue chorus of "I feel old", maybe ....
>> I'm in my early 30s, and the only _mechanical_ typewriter I've seen was
>> an antique originally owned by my grandfather, which my parents used in
>> college (long before I was born) and kept in storage for sentimental
>> reasons. I saw a few electronic typewriters in school, but they had all
>> disappeared by the time I graduated, and I can't recall having seen any
>> since then; kids just a few years younger than I likely wouldn't
>> remember them at all.
>
> Probably typical .... At my CPOE the support staff say they still
> want one typewriter, since it's the best tool for one or a few
> form-filling-out jobs.
unless of course you substitute "one or a few" with "many" ...
bye
Azazel
OK, I'll bite. :) What misuse? "Kids just a few years younger than I
[am]" is correct.
--
Az.
Ben Bacarisse
<OT>
If the verb were there, then "I" would be unquestionably correct.
Without it, opinion is divided though not, I'd venture to say, 50/50.
The use of "I" forces "than" to be seen as a conjunction rather than a
preposition, and for some people that's fine -- the sentence is just an
elliptical form of the version with the verb ("am") present. For
others, it sounds stilted and old fashioned. I'd say that calling it
"misuse" is stretching the point but, which ever way you see it, I'd bet
that the younger the kids the _more_ likely they would be to spot is.
The trend is definitely away from anything that sounds so formal.
Without a following clause that needs a subject (i.e. when the verb "am"
is missing) the use of "me" forces "than" to be seen as a preposition.
This is nothing new (it's been happening for centuries) and I don't
think there can be any serious objection to it these days. In that
sense, "me" is better here and I'd bet that most people would prefer it
over "I".
It's interesting to note that this conjunction/preposition distinction
sometimes makes a lot of difference. In Henry VI, Part III the king
says:
Then why should they love Edward more than me?
Had he said "than I" it would have meant something else entirely.
</OT>
--
Ben.
Stephen Sprunk
> Azazel <aza...@remove.azazel.net> writes:
>> On 2011-06-22, Eric Sosman <eso...@ieee-dot-org.invalid> wrote:
>>> On 6/21/2011 8:49 AM, Stephen Sprunk wrote:
>>>
>>> Kids a few years younger still wouldn't even notice the
>>> misuse of the nominative case.
>>
>> OK, I'll bite. :) What misuse? "Kids just a few years younger than I
>> [am]" is correct.
>
> <OT>
> If the verb were there, then "I" would be unquestionably correct.
> Without it, opinion is divided though not, I'd venture to say, 50/50.
>
> The use of "I" forces "than" to be seen as a conjunction rather than a
> preposition, and for some people that's fine -- the sentence is just an
> elliptical form of the version with the verb ("am") present.
That is what was taught in my schools: the verb is implied and therefore
the nominative (aka subjective) case should be used.
> For others, it sounds stilted and old fashioned. I'd say that calling
> it "misuse" is stretching the point but, which ever way you see it,
> I'd bet that the younger the kids the _more_ likely they would be to
> spot is. The trend is definitely away from anything that sounds so
> formal.
Using the accusative (aka objective) case is definitely more common, to
the consternation of English teachers across the land. I even use it
when the situation demands more informal language--but I do so with full
knowledge that it's "wrong". OTOH, most of my generation has no clue
how to speak or write formally when required.
> Without a following clause that needs a subject (i.e. when the verb "am"
> is missing) the use of "me" forces "than" to be seen as a preposition.
> This is nothing new (it's been happening for centuries) and I don't
> think there can be any serious objection to it these days. In that
> sense, "me" is better here and I'd bet that most people would prefer it
> over "I".
Cases in English have been declining (pun intended) for centuries, and
this last vestige will probably disappear in time as well.
> It's interesting to note that this conjunction/preposition distinction
> sometimes makes a lot of difference. In Henry VI, Part III the king
> says:
>
> Then why should they love Edward more than me?
>
> Had he said "than I" it would have meant something else entirely.
> </OT>
Yes; that's one of the few decent examples of why cases are important,
but since we've lost so much already, one could argue it's not worth
keeping them _only_ for pronouns. English's lack of consistency is one
of its biggest drawbacks.
blmblm.m...@gmail.com
Ian Collins <ian-...@hotmail.com> wrote:
> On 06/22/11 08:40 AM, blm...@myrealbox.com wrote:
> > In article<itq41h$nih$1...@dont-email.me>,
> > Stephen Sprunk<ste...@sprunk.org> wrote:
[ snip ]
> >> I'm in my early 30s, and the only _mechanical_ typewriter I've seen was
> >> an antique originally owned by my grandfather, which my parents used in
> >> college (long before I was born) and kept in storage for sentimental
> >> reasons. I saw a few electronic typewriters in school, but they had all
> >> disappeared by the time I graduated, and I can't recall having seen any
> >> since then; kids just a few years younger than I likely wouldn't
> >> remember them at all.
> >
> > Probably typical .... At my CPOE the support staff say they still
> > want one typewriter, since it's the best tool for one or a few
> > form-filling-out jobs. I'd have thought maybe this would be true
> > at many offices, but maybe we're atypical!
>
> These days people prefer to mess around for hours getting all the text
> correctly lined up in their word processor. It's called progress :)
:-) indeed -- but I *think* the jobs for which our support staff want
that typewriter involve actual paper forms for which a word processor
would not be a useful tool.
blmblm.m...@gmail.com
superpollo <super...@tznvy.pbz> wrote:
> blm...@myrealbox.com ha scritto:
> > In article <itq41h$nih$1...@dont-email.me>,
> > Stephen Sprunk <ste...@sprunk.org> wrote:
[ snip ]
> >> I'm in my early 30s, and the only _mechanical_ typewriter I've seen was
> >> an antique originally owned by my grandfather, which my parents used in
> >> college (long before I was born) and kept in storage for sentimental
> >> reasons. I saw a few electronic typewriters in school, but they had all
> >> disappeared by the time I graduated, and I can't recall having seen any
> >> since then; kids just a few years younger than I likely wouldn't
> >> remember them at all.
> >
> > Probably typical .... At my CPOE the support staff say they still
> > want one typewriter, since it's the best tool for one or a few
> > form-filling-out jobs.
>
> unless of course you substitute "one or a few" with "many" ...
Not very important, I guess, but -- huh? I'm not understanding
your point.
Michael Press
> the OS's, so they ended up sticking with EBCDIC.
That is being generous. ASR-33 teletypes using
proto-ASCII were everywhere. A version of ASCII was
promulgated in 1963.
--
Michael Press
superpollo
> In article <4e01a0c9$0$15667$4faf...@reader2.news.tin.it>,
> superpollo <super...@tznvy.pbz> wrote:
>> blm...@myrealbox.com ha scritto:
>>> In article <itq41h$nih$1...@dont-email.me>,
>>> Stephen Sprunk <ste...@sprunk.org> wrote:
>
> [ snip ]
>
>>>> I'm in my early 30s, and the only _mechanical_ typewriter I've seen was
>>>> an antique originally owned by my grandfather, which my parents used in
>>>> college (long before I was born) and kept in storage for sentimental
>>>> reasons. I saw a few electronic typewriters in school, but they had all
>>>> disappeared by the time I graduated, and I can't recall having seen any
>>>> since then; kids just a few years younger than I likely wouldn't
>>>> remember them at all.
>>> Probably typical .... At my CPOE the support staff say they still
>>> want one typewriter, since it's the best tool for one or a few
>>> form-filling-out jobs.
>> unless of course you substitute "one or a few" with "many" ...
>
> Not very important, I guess, but -- huh? I'm not understanding
> your point.
suppose you had to fill several dozens of forms, or worse several
hundreds (happened recently at my workplace).
they give you a bunch of paper forms, then you have to fill them, with
data that is stored digitally somewhere, or that you have to firstly
store for later usage (maybe some more forms are on the way).
see?
bye
--
Abbiamo dimostrato, per chi volesse comprendere che :
1y*x-->0 = -->1y.
blmblm.m...@gmail.com
superpollo <super...@tznvy.pbz> wrote:
> blm...@myrealbox.com ha scritto:
> > In article <4e01a0c9$0$15667$4faf...@reader2.news.tin.it>,
> > superpollo <super...@tznvy.pbz> wrote:
> >> blm...@myrealbox.com ha scritto:
[ snip ]
> >>> Probably typical .... At my CPOE the support staff say they still
> >>> want one typewriter, since it's the best tool for one or a few
> >>> form-filling-out jobs.
> >> unless of course you substitute "one or a few" with "many" ...
> >
> > Not very important, I guess, but -- huh? I'm not understanding
> > your point.
>
> suppose you had to fill several dozens of forms, or worse several
> hundreds (happened recently at my workplace).
>
> they give you a bunch of paper forms, then you have to fill them, with
> data that is stored digitally somewhere, or that you have to firstly
> store for later usage (maybe some more forms are on the way).
>
> see?
*Oh* .... All is clear now; thanks.
I *think* -- though I could be wrong -- that the typical use case
for our support staff involves, hm, I'm not sure what the term is,
but the physical form is not a single sheet of paper but a stack
of sheets, such that writing/typing on the top sheet results in
the writing/typing being copied onto the other sheets as well.
If one needed to fill out many of these, then .... It would
certainly be tempting to put a bit of work into doing something
that would allow you to get the information directly from some
digital source; it's just not clear to me how you could print onto
the multicopy forms, and if you couldn't, whether a substitute
would be acceptable.
In the long term -- and probably not so long, really -- the people
who are still using those multicopy forms will probably replace
them with something more compatible with the digital world. In the
short term, one does what one can, I guess.
superpollo
as far as i know, even banks abandoned multicopy (carbon copy) forms
long ago. the birth of the laser printer rendered them obsolete, don't
you think? they are a remnant of a time when secretaries had to use them
to reduce typing time of copies and xeroxes were not available.
bye
--
La Tunze e' stata ampiamente dimostrata, ora sta a voi
scienziati doverla applicare.
blmblm.m...@gmail.com
[ snip ]
> > In the long term -- and probably not so long, really -- the people
> > who are still using those multicopy forms will probably replace
> > them with something more compatible with the digital world. In the
> > short term, one does what one can, I guess.
>
> as far as i know, even banks abandoned multicopy (carbon copy) forms
> long ago. the birth of the laser printer rendered them obsolete, don't
> you think? they are a remnant of a time when secretaries had to use them
> to reduce typing time of copies and xeroxes were not available.
Obsolete or not, they are still in use for some things at my CPOE;
a few weeks ago I had a task that involved filling out about a
dozen of them, with a lot of information repeated on all of them,
and indeed it was very tedious [*]. I think this particular
aspect of the CPOE is in transition -- it was pretty much all
done with paper forms when I was hired, and over the years more
has transitioned to being done electronically, but the transition
is apparently not complete. I would guess that there might be
other workplaces in which similar situations exist. Possibly
it's more common in smaller organizations.
[*] Then again, this task was only necessary because I had made a
mistake that could have been avoided with better planning (details
not interesting enough to type up), and it made more work not
only for me but for a colleague, and I figured that maybe the
tedium was deserved ....
(Sorry about the long digression here, folks. Maybe we're done
now, though?)
Robert Wessel
wrote:
Obsolete or not, they still exist. Most car dealers still have impact
printers to print up their multi-part sales documents (and you can
still find a few new-build impact printers out there). But they work
well for sales contracts in some cases, especially if it's done away
from your home base. You can mark and annotate carbonless forms, and
all the copies get the same stuff. You also see occasional use of
the multi-part credit card chits as well (often trades people do at
job). And the occasional form is sometimes quicker to type (and
neater than hand writing it).
That being said, there's one typewriter here, back in a corner. It
probably gets used two or three times per month. And that was often
enough for us to replace the old broken-down one a couple of years
back.