Re[2]: modem problems

[TENCC01.LEWIS01]

Actually, it's worse than just what follows the "CONNECT".  If the line
quality goes down, most modems will drop speed accordingly.  That would
mean an change in speed at the tty "on the fly".  That is rather hard to
predict...

jim


__ Reply Separator _
Subject: Re: modem problems
Author:  [EMAIL PROTECTED] at ~AMSCCSSW
Date:10/26/97 9:13 PM


Andrew J Tarr <[EMAIL PROTECTED]> writes:

> No, it wasn't. Yes, it fixed it, thanks a lot. I don't suppose anyone
> wants to explain why it needs fixed serial speed?

Because there is very little Linux software that adjusts the TTY speed
according to what follows the "CONNECT".  I suspect that it might be
possible to convince mgetty to do it, but minicom and pppd won't.
Also, a 14.4K connection can sometimes get more data - I got 3K/s
downloading some Postscript files.

--
Carey Evans  <*>  http://home.clear.net.nz/pages/c.evans/  gc

   Neniu anticipas la hispanan Inkvizicion.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: what is the sticky bit?

[TENCC01.LEWIS01]

 Forwarded with Changes ---
From: [EMAIL PROTECTED] at ~AMSCCSSW
Date: 10/1/97 9:57AM
To: James M. Lewis at ~TENCCT1
*To: debian-user@lists.debian.org at ~AMSCCSSW
Subject: Re: what is the sticky bit?
---

Actually, the sticky bit used to be for binary programs.  It caused the
program to be retained in the swap file after it was first run.  This
would cause the prog to run faster the next time it was invoked.  Way
back when (in the olden days), unix would exec a program by copying it
into swap and then allowing the page mechanism to page it into memory
for execution.  This is not the case anymore.  As far as I know, the
sticky bit on an executable file does nothing.  On some systems, the
sticky bit on a _directory_ means that only the owner of a file in that
directory can remove it.  DEC OSF1 is like this, for example.

jim

__ Forward Header __
Subject: Re: what is the sticky bit?
Author:  [EMAIL PROTECTED] at ~AMSCCSSW
Date:10/1/97 9:57 AM


Paul Miller wrote:
>
> I know this is a really stupid question.. but what is the sticky bit?
>
> -Paul

The sticky bit allows a UID to be the owner of a file while
that file is being accessed by that user. In essence if a user
opens a file, that user will be the owner of that file until
it is closed. After closing, the file goes back to its original
state.

 I THINK 


Peter


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: IEEE POSIX Standards and Linux

[TENCC01.LEWIS01]

I can't say debian is "posix conformant".  However, I have been
developing c code on hpux, dec osf1, and aix for some years now.  Linux
is as good as any of those.  When it comes to supporting old standards
like bsd, linux is probably a bit better.

To be an actual factual posix system you have to pass a test suite that requires
a bunch of money.  If the test suite is ever put in public domain, linux may get
a posix rating.

jim

__ Reply Separator _
Subject: IEEE POSIX Standards and Linux
Author:  [EMAIL PROTECTED] (SMTP.MNETO1) at ~AMSCCSSW
Date:9/25/97 9:23 PM


Dear Sirs,

  I am a Linux user and I need information regarding linux (debian,RedHat,
Slackware) and its conformance to IEEE POSIX standards, specially those
that Microsoft Windows NT is not compliant.

  Best regards,

Mario de Mello B. Neto.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re[2]: Stable means not-changing?

[TENCC01.LEWIS01]

On the bash thing...

I think it was a posix compliance thing.  The man page for the posix
shell states that "{" and "}" are reserved words and the usage is like:

{ list ; }

The man page also states that ";" is a metacharacter that can be
replaced by one or more newlines.  So the following would presumably
also work:

{
   list
}

I also checked the ksh book (The Kornshell Command and Programming
Language) and it said the same thing (in more explicit language on page
125 & 161).

It seems to me that bash should have honored its extension to allow

{ list }

in any event.  The key here is that it was always an extension and not
"standard" behavior.  How serious a bug it is depends on how much you
follow posix.  I probably would not have seen this bug since I use linux
as a home environment to support my work on hpux and dec osf1.  Those
systems require the posix/ksh form...

jim


__ Reply Separator _
Subject: Re: Stable means not-changing?
Author:  [EMAIL PROTECTED] at ~AMSCCSSW
Date:9/24/97 8:24 PM

[cut stuff]

--Pete

[*] Does anyone know where there was a doc explaining that "{ foo }"
suddenly had to become "{ foo; }" when upgrading to Bash-2.0?  That
only choked on about a hundred of my scripts that had worked fine
under 1.14 (or whatever it was)...


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re[2]: 'tell' is missing from libc6

[TENCC01.LEWIS01]

for what its worth...

There is no man page for "tell" on hp-ux, dec unix, or aix.  However, a
simple program that calls "tell" will load so the routine exists in all
of those environments.  Using nm confirms "tell", "ftell", "telldir",
and variants with one or more _'s in front (but no "ltell").

jim

__ Reply Separator _
Subject: Re: 'tell' is missing from libc6
Author:  [EMAIL PROTECTED] at ~AMSCCSSW
Date:9/19/97 9:45 AM


> > It appears the "tell(path)" command is missing from libc6.  What
> > should I be using instead?
>
> The only "tell" that I could find in libc-5.4.33 is the following one:
>
> file sysdeps/linux/tell.c:
>
> off_t
> tell (int fildes)
> {
>   return __lseek (fildes, 0, SEEK_CUR);
> }

That's the one.


> If that is the right function the replacement should be obvious using
> the syscall lseek, but you should prefer the use of ftell on FILE* if
> possible.

In this case, I don't have a FILE*; only a path number.


> If this is the wrong function you should tell us what tell(path)
> is doing, I haven't heard of such a function yet.

To quote "C: The Complete Reference" (by Herbert Shildt):

  The function "tell()" is part of the UNIX-like I/O system and is not
  defined by the ANSI standard.

Thus, I think libc6 should include it.  It appears that libc6 now includes
a manpage for "ltell" (which, I agree, is what the function should have been
named in the first place).  However, for compatibility reasons, there should
be a "#define tell(a,b,c) ltell(a,b,c)" in .

Can anybody confirm if "ltell" exists in libc5?

  Brian
 ( [EMAIL PROTECTED] )

---
 It's not the days in your life, but the life in your days that counts.



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re[4]: Debian + PC with multi RS... port -> n x (text d

[TENCC01.LEWIS01]

My experience is with hp terminals using enq-ack protocol.  When you
send stuff to one of the "devices" (screen, printer port, mini-tape,
etc.) the keyboard gets locked for the duration of that transfer.
Usually, this is not very long.  If the line is fast, you don't have
much time to do anything between transfers.  The program I wrote used
binary transfers so we could dump raster graphics to the terminal
printer.

There are other ways to do it than the one I used but it requires a
tricky driver in the operating system.  Old hp rte systems used to be
able to read/write to the mini-cartridge tape system in the 2645
terminal while you did something else on the screen.  If you limit the
data to simple ascii print, you have a much better chance.  If the stuff
you write is really short (less than 2k) then the time you can't type is
going to be pretty short.

vt terminals... I don't know.  I have no idea how they handle the
keyboard when you dump stuff to the printer port.

The problem can be solved.  You have to know a *LOT* about the terminal
you are going to use.  There are always some tricks that you have to
learn that aren't in the manuals.  (These days, there isn't much in
manuals anyway.)

jim lewis



__ Reply Separator _
Subject: Re: Re[2]: Debian + PC with multi RS... port -> n x (text d
Author:  [EMAIL PROTECTED] at ~AMSCCSSW
Date:9/12/97 7:38 PM


On 12 Sep 1997, TENCC01.LEWIS01 wrote:

> It probably doesn't work the way you want.  Usually the terminal keyboard is
> locked until the print is finished.  Making the terminal useful for input at
the > same time is generally not possible.  It would require a very clever
terminal > and an extremely clever driver. > > jim >

... Or just a larger RAM buffer in the printer and hopefully a fast line,
after all I don't think that in a POS system anyone would need to print
large reports at one of the terminals, most likely just a few lines on a
page for each sell or incoming materials. I would choose to connect a
printer to the port _on_the_main_computer for large reports. But it would
be interesting just to know more about that keybord lock during prints.


 Nicola Bernardelli <[EMAIL PROTECTED]>
---
 Please use <[EMAIL PROTECTED]> for messages from any kind of
robot, such as mailing lists. From that address no autoresponse
messages will return even when I'm not at home.
---


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re[2]: Debian + PC with multi RS... port -> n x (text dumb t

[TENCC01.LEWIS01]

Printing to the aux port of a terminal has been done before.  SCO Xenix used to
do it (about 10 years ago) with Wyse terminals. I have heard about printing
through vt type terminals off dec vax machines. I once wrote a program to do it
through hp terminals (with rte-a, not unix).

It probably doesn't work the way you want.  Usually the terminal keyboard is
locked until the print is finished.  Making the terminal useful for input at the
same time is generally not possible.  It would require a very clever terminal
and an extremely clever driver.

jim

__ Reply Separator _
Subject: Re: Debian + PC with multi RS... port -> n x (text dumb ter
Author:  [EMAIL PROTECTED] at ~AMSCCSSW
Date:9/12/97 8:35 AM


On Fri, 12 Sep 1997, Joey Hess wrote:

> Nicola Bernardelli wrote:
> >   1) what about sending output TO A PRINTER which is NOT ON A PARALLEL
> >  PORT (lpt1, lpt2, ...) but is instead on a serial line? (Maybe I just
> >  need to write software which sends output to its stdout instead of
> >  stdprn, and that output is merely redirected to a com port... maybe
> >  such multiuser environments have typical and by now "traditional"
> >  solutions to my question... that's why I said I lack the basics.)
>
> I think you need 2 lines. Assumming you want your software to be able to
> direct some output to the printer and some output to the serial port, as it
> wishes without human intervention to flip a switch, you need a separate line
> for each.
>
> Also, while it's possible to have a device that prints out what comes to it
> on a serial line, a PC's printer port works quite differenlty than it's
> serial port, (you can't just plug a printer up to it), and so it will be
> more economical to use a standard printer.

But I never heard of PC's with 8 or 16 LPTs, while I hear of multi serial
IO cards with that number of ports.

> >  If yes, would the OS menage the distinction between the two devices
> >  or should _my_application_ (or some wrapper) be aware of the hardware
> >  each session runs on and eventually take care of sending special
> >  characters to say "this goes to the display, this goes to the
> >  printer"
>
> I've never heard of anything that did this. If you actually manage to find a
> serial terminal + printer combo that is switchable from terminal to printer
> mode via some escape sequence, then yes, linux could send the sigals. But I
> think that's unlikly.
>
>  or should I just have two distinct cables run from the Linux
> >  box to the place where the dumb terminal and the printer are?
>
> probably.
>
> > >  1) What serial devices allow longer cables than RS232 without use
> > > of modems (say 10-100-200 meters)?
> > >  2) Are there multi port cards of that kind which run well with
> > > Debian? Any brandname + model?
> > >  3) What if the text dumb terminals connected to a Linux Box also need

> > > a printer each (or almost any of them)? Is it possible that
> > > data is sent to the printer and terminal via the same line?
> > > Brandname + model?
>
> I'll bet you're setting up a point of sale system.

Bingo. I don't feel like doing it so much, but I should _hope_ to instead.


> If I were you, I would set up an ethernet network,

(I wouldn't like so much to have that possibly pretty high number of
ethernet points, I wouldn't like to be called once in a while and have to
go looking for bad connectors and so on... maybe some CPU-intensive task
deserves another complete powerful Debian box, maybe even more in future,
but using ethernet just to have terminal+printer...)

>with a linux server, and POS systems that were 286
> or 8088 machines with printers attached. Then you would set up software for
> the POS systems, to let them function as terminals, and/or output what data
> they receive to their printers. This fixes your cable length problem, you
> only run one cable, and the price is probably not much larger (unless you
> get them for free, dumb terminals cost more than you would expect).

What is a POS system? What software runs on it? What does such a PC need
to boot at startup? What ethernet cards are suitable for a 8088 or 80286?
(And - ignoring noise from the fan and need to boot some software - will
the people for which I will be building the application find good-looking
one-year-warranty such outdated machines? And, last, I will most probably
be stuck at 80x25... ok, I shall anyway _not_ be making assumptions on
that point...).


 Nicola Bernardelli <[EMAIL PROTECTED]>
---
 Please use <[EMAIL PROTECTED]> for messages from any kind of
robot, such as mailing lists. From that address no autoresponse
messages will return even when I'm not at home.
---




--
TO U

Re[2]: Debian + PC with multi RS... port -> n x (text dumb t

[TENCC01.LEWIS01]

Printing to the aux port of a terminal has been done before.  SCO Xenix used to
do it (about 10 years ago) with Wyse terminals. I have heard about printing
through vt type terminals off dec vax machines. I once wrote a program to do it
through hp terminals (with rte-a, not unix).

It probably doesn't work the way you want.  Usually the terminal keyboard is
locked until the print is finished.  Making the terminal useful for input at the
same time is generally not possible.  It would require a very clever terminal
and an extremely clever driver.

jim

__ Reply Separator _
Subject: Re: Debian + PC with multi RS... port -> n x (text dumb ter
Author:  [EMAIL PROTECTED] at ~AMSCCSSW
Date:9/12/97 8:35 AM


On Fri, 12 Sep 1997, Joey Hess wrote:

> Nicola Bernardelli wrote:
> >   1) what about sending output TO A PRINTER which is NOT ON A PARALLEL
> >  PORT (lpt1, lpt2, ...) but is instead on a serial line? (Maybe I just
> >  need to write software which sends output to its stdout instead of
> >  stdprn, and that output is merely redirected to a com port... maybe
> >  such multiuser environments have typical and by now "traditional"
> >  solutions to my question... that's why I said I lack the basics.)
>
> I think you need 2 lines. Assumming you want your software to be able to
> direct some output to the printer and some output to the serial port, as it
> wishes without human intervention to flip a switch, you need a separate line
> for each.
>
> Also, while it's possible to have a device that prints out what comes to it
> on a serial line, a PC's printer port works quite differenlty than it's
> serial port, (you can't just plug a printer up to it), and so it will be
> more economical to use a standard printer.

But I never heard of PC's with 8 or 16 LPTs, while I hear of multi serial
IO cards with that number of ports.

> >  If yes, would the OS menage the distinction between the two devices
> >  or should _my_application_ (or some wrapper) be aware of the hardware
> >  each session runs on and eventually take care of sending special
> >  characters to say "this goes to the display, this goes to the
> >  printer"
>
> I've never heard of anything that did this. If you actually manage to find a
> serial terminal + printer combo that is switchable from terminal to printer
> mode via some escape sequence, then yes, linux could send the sigals. But I
> think that's unlikly.
>
>  or should I just have two distinct cables run from the Linux
> >  box to the place where the dumb terminal and the printer are?
>
> probably.
>
> > >  1) What serial devices allow longer cables than RS232 without use
> > > of modems (say 10-100-200 meters)?
> > >  2) Are there multi port cards of that kind which run well with
> > > Debian? Any brandname + model?
> > >  3) What if the text dumb terminals connected to a Linux Box also need

> > > a printer each (or almost any of them)? Is it possible that
> > > data is sent to the printer and terminal via the same line?
> > > Brandname + model?
>
> I'll bet you're setting up a point of sale system.

Bingo. I don't feel like doing it so much, but I should _hope_ to instead.


> If I were you, I would set up an ethernet network,

(I wouldn't like so much to have that possibly pretty high number of
ethernet points, I wouldn't like to be called once in a while and have to
go looking for bad connectors and so on... maybe some CPU-intensive task
deserves another complete powerful Debian box, maybe even more in future,
but using ethernet just to have terminal+printer...)

>with a linux server, and POS systems that were 286
> or 8088 machines with printers attached. Then you would set up software for
> the POS systems, to let them function as terminals, and/or output what data
> they receive to their printers. This fixes your cable length problem, you
> only run one cable, and the price is probably not much larger (unless you
> get them for free, dumb terminals cost more than you would expect).

What is a POS system? What software runs on it? What does such a PC need
to boot at startup? What ethernet cards are suitable for a 8088 or 80286?
(And - ignoring noise from the fan and need to boot some software - will
the people for which I will be building the application find good-looking
one-year-warranty such outdated machines? And, last, I will most probably
be stuck at 80x25... ok, I shall anyway _not_ be making assumptions on
that point...).


 Nicola Bernardelli <[EMAIL PROTECTED]>
---
 Please use <[EMAIL PROTECTED]> for messages from any kind of
robot, such as mailing lists. From that address no autoresponse
messages will return even when I'm not at home.
---




--
TO U