ANSI bug?
i am thinking there is a flaw in the ANSI code,
and this program demonstrates this 'flaw'. when
the 'inverse' attribute is set on the ANSI color
string, the 'clear to EOL' ANSI string does so
without respect to the 'inverse' attribute.
for example:
NORMAL
Foreground=White
Background=Red
CLEAR-TO-EOL=Red Background.
INVERSE
Foreground=Red
Background=White
CLEAR-TO-EOL=Red Background.
(it makes more sense for CLEAR-TO-EOL
to make a White Background in this instance).
///
int main(int argc, char* argv[]) {
// ESC [ [at] ;3 [fg] ;4 [bg] m
char a[]={ 0x1b,0x5b, 0x30, 0x3b,0x33, 0x37, 0x3b,0x34, 0x31, 0x6d };
char b[]={ 0x1b,0x5b, 0x31, 0x3b,0x33, 0x37, 0x3b,0x34, 0x31, 0x6d };
char c[]={ 0x1b,0x5b, 0x37, 0x3b,0x33, 0x37, 0x3b,0x34, 0x31, 0x6d };
char d[]={ 0x1b,0x5b, 0x30, 0x3b,0x33, 0x31, 0x3b,0x34, 0x37, 0x6d };
char e[]={ 0x1b,0x5b, 0x31, 0x3b,0x33, 0x31, 0x3b,0x34, 0x37, 0x6d };
char f[]={ 0x1b,0x5b, 0x37, 0x3b,0x33, 0x31, 0x3b,0x34, 0x37, 0x6d };
char k[]={ 0x1b,0x5b,0x4b }; // clear to EOL ...
char* s=0123456789;
write(STDO, a, 10); write(STDO, k, 3); write(STDO, s, 10); printf(\n);
write(STDO, b, 10); write(STDO, k, 3); write(STDO, s, 10); printf(\n);
write(STDO, c, 10); write(STDO, k, 3); write(STDO, s, 10); printf(\n);
write(STDO, d, 10); write(STDO, k, 3); write(STDO, s, 10); printf(\n);
write(STDO, e, 10); write(STDO, k, 3); write(STDO, s, 10); printf(\n);
write(STDO, f, 10); write(STDO, k, 3); write(STDO, s, 10); printf(\n);
// 'c' and 'f' do not inverse the clear to EOL ...
exit(0); }
///
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
MD5 errors
i was downloading 7.0-RELEASE, and found the following MD5 errors: doc/ ERROR: MD5 (doc.cc) = a83976995e055dbe67030397902c5ab9 MD5SUM MD5 (doc.cc) = 662363b086db1164eb922024428df2df ERROR: MD5 (install.sh) = 0ddd67ac6a0ca00e0131f63bcde9b145 MD5SUM MD5 (install.sh) = a1f597bcc955e069fd6679ea4a543d19 kernels/ ERROR: MD5 (install.sh) = 7f507448f530c624c9b0d9e4881c148f MD5SUM MD5 (install.sh) = 766fb0b8d2332d5cb5f70be4ec00ea7b src/ ERROR: MD5 (install.sh) = 311278afa5305731822fbfa8d1de2805 MD5SUM MD5 (install.sh) = fa16a2a3b7a8b4ec6f4eada5eb5bb326 i am worried about doc.cc, because the file size is very wrong. can anyone please verify that it is safe to install with these broken MD5 sums before i try to install? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
display power
can someone tell me how to stop FreeBSD (4.11) from turning off my monitor (after whatever preset timeout there is)? it's messing my monitor up because it takes my monitor about an hour to stabilize the display after being turned off - and i can't afford a new monitor right now. until it is warmed up, it squiggles all over to the point where nothing can be seen or read on the display. thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
VIA C3 - cant boot CD
i have an ML6000 (no floppy) and have downloaded the 4.11 mini-iso image, and burned it to a CD-RW. CPU: VIA C3 Nehemiah (666.55-MHz 686-class CPU) after rebooting, the CD is found, and a boot attempt is made. within 5 seconds, the kernel locks up after about 3 seconds of the kernel data+234238 text+23432 stuff and the /-\|/-\ twirling prompt, leaving a / as the first character on the next line. the ISO is the exact size it should be, and i could gzip -t mfsroot.gz in the /boot directory without error - so i guess it's a good image. i am running 4.10 currently, and have no boot problems off the hard drive. any ideas as to what could cause this lock-up at boot time? i thought the ISO's are made with the mkisofs --no-emul-boot, yet the CD is recognized as a 2.88 floppy, and boots 0:fd(0,a)/boot/loader. i never booted off CD's before, and don't know what i should expect exactly. thanks. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
burncd problems
FBSD 4.10 keywords: burncd cdrw 700 650 device busy i have had seemingly inconsistent problems/errors with 'burncd', and i exhausted myself on it the past few days trying to prepare a bunch of CD sets. to possibly prevent others from struggling, this is some information i have found which may be helpful to others: older or cheap CDRW drives can't deal well with 700MB CDRW's. they may work, or may not. they can't track on the thinner tracks well. i would have some CDRW disks that worked flawlessly, and others that were a real pain within the same brand. some CDRW disk manufacturers are better than others it seems. Memorex 700MB disks seem to be particularly problematic for older/cheap drives. if you got an older/cheap CDRW drive, stick to 650MB, or at least avoid Memorex 700MB disks. i had trouble with Memorex 700MB disks on a Creative 8x4x32 speed drive. when i upgraded to a 48x24x48, all my problems with Memorex 700MB disks went away. acd0: CD-RW CREATIVE CD-RW RW8435E at ata1-master PIO4 acd0: CD-RW CD-RW 48X24at ata1-master PIO4 it is difficult for the average user to figure out, because all you ever see is drive busy errors - and that doesn't tell you much. but from my reading, CD drives don't tell a driver too much, so that's all that can be said. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
burncd + ioctl
FBSD 4.10 $ burncd -s4 -f/dev/cdrom erase erasing CD, please wait.. burncd: ioctl(CDRIOCBLANK): Device busy everyone seems to have this problem, and i have had it myself for years. most times, powering off/on fixes it - but if that is a satisfactory fix for FBSD - i may as well use MS Windows. this time, no amount of powering off/on is fixing the problem. i have tried 10 different blank CD's (the problem seems to occur with blanks most often - usually occuring after a burncd operation is aborted). i have seen the bug reports closed with the advice of turning off DMA, but after trying every single 'atacontrol' option, nothing changes. everything works ok as long as i use CD's that have been written at one time, but nothing works with 'from the store' blanks now. yet the same drive and CD's work under MS Windows just fine. please fix this problem. it's a real pain. and it's been going on for years. problem reports shouldn't be closed because someone resolved something by powering off and on. that's MS technique. i don't suppose i will hear it is fixed, and i don't suppose anyone has a sure fire way to get around it - there are no satisfactory answers on google or in the maillists or bug reports. so for whatever it's worth, the problems continue. -- [as an aside, why isn't it 'atactl', i hate having to type out the whole word - it feels so 'boneheaded' - and how about some consistency - sometimes it's 'ctl' then 'cntl' then 'control' - good grief]. [as another aside - i have been using FBSD since the 1.x days, and ever since the 3.x series - more so in the 4.x series - i have been able to easily crash/lock up machines - especially in X - especially when doing multimedia stuff and then CTRL-ALT-F?-ing to a ttyv? terminal. i hate having to be careful of how heavily i am stressing my machine. FBSD didn't used to be like that - it used to stand up to any amount of abuse - and without all the response latency i experience these days.] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
burncd + ioctl
FBSD 4.10 CREATIVE CDRW acd0: CD-RW CREATIVE CD-RW RW8435E at ata1-master PIO4 after rebooting and power down and spending more time trying to trick the CDRW into doing something, i finally tried: $ burncd -f /dev/acd0 erase file.iso the 'file.iso' seemed to force 'burncd' to do something - eg - make the CD light blink. after hitting up arrow-enter 100x, after a lot of -1 errors, it finally started to erase. and then it started to work again. i can't make complete sense of it yet, but possibly there are software methods around the glitch of the previous post. another method i had success with a few times was to put a CD with files and a filesystem in the drive, which would mount/list OK, and then 'detach' the CDRW with atacontrol, and then stick a problematic 'from the store' blank in the drive, then 'attach', and then it could be 'erased' with burncd. the best i can figure is, there's something funky about 700MB CDRW media, everyone seems to have a problem with it in a freaky way: RE: PCWorks: 700 MB versus 650 MB CDRW? _ * From: Carol Warman * Subject: RE: PCWorks: 700 MB versus 650 MB CDRW? * Date: Sat, 22 Jun 2002 19:27:09 -0700 _ Peter: Yes, this was exactly the problem. They were Memorex 700MB discs, right out of a brand new box. The firmware probably needed upgrading to see these discs. The issue was resolved by using Imation 650 MB discs. Thanks so much for the input. Carol Warman Computers Were Us, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Kaulback Sent: Saturday, June 22, 2002 7:05 PM Subject: RE: PCWorks: 700 MB versus 650 MB CDRW? Some cdrw discs manufactured by Memorex in particular, my burner will not even see. In effect they fail to exist. What drives do you have, they may only need their firmware to be updated. Peter Kaulback In the hour of 11:11 AM 6/22/2002 -0700, Carol Warman spoke this: Gerry: Thanks for the reply and for the valuable links. Would you know whether a CD RW drive manufactured 1-2 years ago (the age of the two machines in question) would have a problem in writing a 700 MB disc? I'm interested in tracking down the reason that the 650 MB media worked flawlessly and the 700 MB did not. Any thoughts? Thanks. Carol Warman Computers Were Us, Inc. [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gerald E. Boyd Sent: Saturday, June 22, 2002 8:22 AM Subject: Re: PCWorks: 700 MB versus 650 MB CDRW? At 07:41 PM 6/21/02 -0700, Carol Warman wrote the following: Could someone please explain the difference (other than the obvious capacity) of a 700 MB CDRW versus a 650 MB CDRW. I am asking because we helped a client back up his files today and both of his CDRW drives (in two separate machines) would not recognize this media. Once we inserted a 650 MB CD, both drives recognized the media and the copying worked fine. I am used to working with the 650 MB media and the 700 is new to me. Early CD drives hold about 74 minutes of audio, or about 650MB of data. Later models hold about 80 minutes of audio, or about 700MB of data. The change came about because of all the audio fans overburning the original CD (circa 1997) to achieve longer play times. Hence, the manufacturers just started making the newer sizes. For more info, see the CD-R FAQ (start at section 7-6) http://www.cdrfaq.org/faq01.html -- Gerry Boyd ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
pc speaker to sound card
FBSD 4.9R is there anyway to route PC speaker sounds to my sound card? specifically, my PC speaker is fried, and i would like to hear ytalk beeps thru my sound card ... thanks (please copy any replies off-list). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vt/ansi codes
i am just trying to understand. there are things i don't like, and want to do better. i don't know where else to learn, i do search and read and study whatever i can. i do read with intent to learn. it appears to come down to an argument of: support everything ever made in the world or otherwise do-able regardless of efficiency and complexity vs. support 95+% of possibilities with a 95% reduction in overhead and inefficiency. i have no interest in arguing, only understanding. i think i got an itch cuz after 25 years of seeing the same old procedures when technology is not comparable in any way 25 years later - well - heh - things need to evolve or die. and i do not see good argument in opposition to evolution of code. and i agree it may be out of ignorance. but not lazy ignorance. just ignorance of insufficient facts. Terminal driver design is certainly a stupid part of Unix. Back when this was written there certainly was a serious mess of terminals which would actually fail non-gracefully on output designed for other terminals. But this is not true today. Today EVERY SINGLE TERMINAL IN THE WORLD understands ANSI escape sequences at full speed and will not choke (and will likely display) on all ISO-8859-1 characters. Shall we count the ways that this is wrong? 1) There exist terminals in the world which do not understand ANSI escape sequences. what are the facts? where are the facts? who has these terminal usage statistics? there appear to be no facts. i can't find any. and none are put forth. just because something exists doesn't mean it's relevant to anything. and just because there exist some terminals that don't understand the full ANSI escape standard doesn't mean that the full ANSI escape standard shouldn't be implimented in BSD terminal drivers. as i see it, there is one MAJOR flaw, and that is LEFT/RIGHT scrolling. without the proper ANSI escape sequence, L/R scrolling in color is doomed to be 100x more ineffecient, which is a disaster for text editing across serial lines. i have not heard any way termcap/curses can work around this deficiency. scroll regions would be nice as well for applications requiring status lines. i haven't heard a single reason why these simple things are not part of BSD terminal drivers. if i knew enough about integrating things with the kernel, i'd write new terminal related drivers myself. 2) There exist terminals that do not work at arbitrarily high wire speeds, and thus operate at low baud and/or require delays and padding for certain operations. there exist many things. 3) Most terminals display either the high-bit VT100 character graphics, the IBM 437 codepage (aka MS-DOS character graphics), or nothing at all. I can't point to any physical device-- not one-- that I have which displays the accented characters from ISO-8859 by default. It is time to scrap every single option in the editing portion of the terminal driver. And start accepting *both* ^H and ^? as backspace. The first suggestion requires a replacement that one would scrap the editing portions of the terminal driver with. Nobody has come up with a better replacement yet. ^H is backspace, ASCII bs. ^? is ASCII del. Some people expect them to work alike; others seem to want one to delete backwards and one to delete forwards. It would be nice if people agreed on this matter, in the same way that it would be nice if people stopped killing each other in the name of fun and religion... I would agree that in this area, morbid fear of being incompatable is completely freezing development. Sometimes advancement is achieved by DELETING code, not just by adding it. but I don't conflate the relative importance of a dispute about arcane aspects of computing and, say, the conflict in the Middle East. Morbid fear is pretty strong language and is perhaps appropriate when discussing the latter issue, but likely not appropriate with regard to the former issue. -- -Chuck PS: No, I don't want to discuss politics: it's off-topic. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vt/ansi codes
Re:Starting with Unix (Score:4, Insightful) by spitzak (4019) on Sunday April 27, @01:18PM (#5819797) (http://www.cinenet.net/~spitzak) Terminal driver design is certainly a stupid part of Unix. Back when this was written there certainly was a serious mess of terminals which would actually fail non-gracefully on output designed for other terminals. But this is not true today. Today EVERY SINGLE TERMINAL IN THE WORLD understands ANSI escape sequences at full speed and will not choke (and will likely display) on all ISO-8859-1 characters. It is time to scrap every single option in the editing portion of the terminal driver. And start accepting *both* ^H and ^? as backspace. I would agree that in this area, morbid fear of being incompatable is completely freezing development. Sometimes advancement is achieved by DELETING code, not just by adding it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vt/ansi codes
You don't think you're alone because you've Googled a lot? heh :) namely, i am not happy with the current selection of text editors (i find joe(1) to be very good, but it's got some problems and is aging without good development), 136-sec# ls /usr/ports/editors | wc -l 200 yeah, 200 - great :) tried all of them ... i've been using FBSD for almost 10 years, since version 1.X (1995 or so?). and the same old rebuttals continue - with no real advance. look - 200 editors. heh (in good humor) :) more of my favorites are: Q. i want to know how to write to the display like i used to in DOS ... A. UNIX is not DOS. what a stupid question. have a nice day. goodbye. heh. or: Q. isn't there an editor for non-gurus to use to set up a system? A try vi, you'll like it, it's smarter, better. if you're too stupid to use vi, you're too stupid to use this OS (pre-ee days :). heh. i have used vi, and i did learn it, and IMHO, it still sucked because whatever i could do in vi in 10-20 keystrokes of crypto, i could do in 2-3 mnemonic keystrokes in joe. plus, i could do even more stuff in joe that i couldn't do in vi. of the 200 editors, most are either graphic apps, vi/emacs clones, or total pieces of garbage - they really need to be weeded out. and the various language specific stuff should really be in their own trees. i would guess people looking for a Korean text editor don't want to wade thru Japanese editors, and people looking for plain ascii editors don't want to wade thru gobs of Japanese, Korean, and graphic editors. my point is things need to be rethought. redone. reworked. and the failure to do so is crippling OSOS's (Open Source OS's). and all OS's in general. my specific point (as an example) was that if a decent fully functional ANSI escape sequence standard was adopted by all terminal drivers - cross platform code would be much more efficient in size and CPU time with less dependencies, much easier to maintain and port, accessible by ALL programming languages in the same way, displays would look nicer, much more useful and interesting code would be developed, and i don't see or hear an intelligent reason not to do so. and the same goes for FS hierarchies and many other things, and all the configure/libtool/automake/pkgconfig stuff. people say oh it's great, more stuff to do more stuff on more things. but after this tree of more stuff grows a while, hello world becomes a complication where one has to hack termcap, ncurses, termios and sys/ioctl; and then configure/libtool/automake/pkgconfig, and then figure out numerous OS packaging schemes. all opposing arguments are to the effect of what about using this library, and what about this hack and that hack. forget it - people only have so much time in life. a goal should be to create OS's that allow effective and efficient and lasting creation - not endless and fundamentally pointless years of study to climb mountains around bad foundations. extended regex's should be standard - things like sed -E and grep -E and find -E and all this nonsense needs to go. it's causing more hours of pain dealing with the nonsense than it would have caused to simply say starting January 1, 2002, sed/grep/find will all link with extended regex libraries - please update any scripts. and further continuation should be shunned. IMHO, there's too much consideration given to compatibility with ancient code sitting on obscure PDP mainframes with VT100 terminals, and far too little consideration given to the evolution of quality technical product (i don't know anything about kernel developments, this is only a engineer with a programming/OS hobby viewpoint). and that's why in the MS windows arena you find countless more quality programs and software. cuz those same programmers in the UNIX world would quit before completion of any project due to the endless and pointless overhead and mundane incompatibilities and nuisances across UNIX platforms. in UNIX, arguments (more or less) come down to ATT did such and such in 197X, so therefore ... bunk. if ATT (or DEC, et al) did something lame (compared to todays understandings/technology) in 197X, it's really not a good reason to continue with it. it's past time to do things better than ATT (or DEC et al) did them in 197X. methods should evolve more and more on technical merit and less on ancient history or however SUN/IRIX does it (remaining backwards compatible when not in danger of creating a real kludge); and driven with the goal of a more intelligent/higher quality product that evolves without regard to marketing hype and schedules. if a programmer is gonna spend time and work in the open source arena, that should be (and is) a major justification - what else? (albeit, many are driven by socialistic/anti-MS energies). the open source community as a whole has power to lead and forge standards, and to continue to follow blindly in the proprietary footsteps of quarter century old
Re: vt/ansi codes
[EMAIL PROTECTED] wrote: [ ... ] the basis for this question was to determine if it was feasible to write a portable FBSD application and/or library without external dependencies. You can write portable ANSI-C code using the STDIO routines, without external dependencies upon termcap, ncurses, or anything else but libc. it is understood what ncurses and SLang are for - and initially ANSI escape sequences seemed to provide a way to break through the burdens and complications of ncurses and termcap entries. Which are? Precisely what are you trying to do? Do you need color? Are you using plain text-mode stuff, or do you need bitmapped graphics? If text-mode, do you need cursor positioning? Do you care whether your code runs on anything but an Intel box? -Chuck over years of coding, i got fed up with some basic things. after 1000's of pages of google-ing, i don't think i am alone. namely, i am not happy with the current selection of text editors (i find joe(1) to be very good, but it's got some problems and is aging without good development), and i am not happy with the current selection of terminal based browsers (i understand mc(1) to be the only real choice). these are critical to me as they things i use probably more than anything else. and i am tired of crazy configuration files. so i started out preliminary designs of an ANSI based terminal I/O and rc configuration (key/display/macro bindings, etc) library. and i am also tired of 'broken' terminal stuff like window(1) and talk(1)/ytalk(1) - neither of which do color, and which require special termcap tweaks that never seem to work right, specifically when using editors and other terminal programs (such as lynx) inside these terminal windows across serial connections, and i don't think they are efficient over slow (modem) serial connections where i do much of my work. i think in 2003 i should be able to use basic terminal stuff with color in a standard/efficient/basic way. but i admit, i could be dreaming. i'd also like control a terminal from various scripting languages (sh/awk/whatever) with ANSI escape sequences - things that would be a real pain/kludge to do any other way. anyway i checked out SLang and ncurses, and while i see the good aspects of these things, i see many things that i don't like, off the top of my head: a) i don't like their size (near half a megabyte for libncurses.a). things like a browser/editor need to be statically linked to use in single user mode. i prefer things to be useful on old systems/embedded systems/boot+install floppies. b) i don't like their complexities/API. i don't want to spend more than a few days mastering a fairly complete terminal I/O API. i think a person should be able to program competently within a day. the learning curves are fairly steep and are a deterrent to many wannabe programmers that don't have time in life to attain guru status but nevertheless would otherwise make valuable contributions. c) i assume (with a degree of ignorance) they must be nightmares to maintain, and based on what i've read - there's long histories of bugginess other crazy stuff due to overbroad attempts at compatibility (like SLangs regex's for example). d) neither SLang nor ncurses are available to scripts as ANSI escape sequences are via simple echo/printf statements. e) i assume (with a degree of ignorance) they must be inefficient over slow serial connection just based on the limited vtXXX capabilities of the vt/pcvt and xterm drivers. since they can't interpret scroll left/scroll right/scroll regions, screenfuls of data are being sent just to move past a leftmost/rightmost column or to scroll a tiny portion of a display. this is multiplied with use of color. for example, if i have a 80x60 color display, that's 4800 chars + 4800 * 10 (attribute and color escape sequence/char), or 52,800 characters that must be transmitted - when at most - with ANSI 3.64 scroll left/right sequences - this figure would be 60+60*10, or 660 characters - almost 100x faster updating. in my semi-ignorant estimation, there is a big problem in lack of terminal standardization and vtXXX deficiencies that could be very nicely resolved if the open source community would define and implement as fully functional and complete set of ANSI escape sequences that could reliably be used across all platforms/terminal drivers within a raw terminal state. for workstations using terminals that use proprietary ANSI command sets - an optional library that re-interprets the I/O of a uniform ANSI superset could be made available, one which could work transparently via the ANSI terminal ident escape sequence. it's just my semi-ignorant humble opinion that a new ANSI standard needs to be developed to move UNIX terminals past circa 1977. are my grandchildren going to be stuck with vt100 in 2077?
vt/ansi codes
i am trying to develop terminal I/O based code, and found myself meandering down a path to acquire terminal knowledge (i don't need to be told of SLang/ncurses/...). i can't readily find an answer to this, but i am assuming DEC terminals don't scroll left/right? i've never used a terminal, so i wouldn't know. there are ANSI escape codes that would be great to use, but from the knowledge i have been able to acquire, it appears vtXXX stuff is a fairly lacking subset of ANSI 3.64 terminal display functions. there's many aspects of ANSI 3.64 that would make display updates over serial connections MUCH more efficient than using vtXXX only codes. any comments providing a better understanding about this would be appreciated - cuz i'd hate to write a bunch of inefficient code just to find out i *could* scroll left/right with an ANSI escape sequence, etc. my goal is to generate a minimal set of reliable cross-platform ANSI escape codes one can use without fear of incompatibility. maybe this is an impossibility - i dunno - but there are a few sequences that seem to permeate most data sheets. as i read that this ANSI stuff was done way back in 1979 - before i bought my Apple 2e, i can't help but gawk with disbelief as i find UNIX vtXXX terminal stuff to still be fairly primitive a quarter century later. i mean, an entire screen shouldn't have to be sent over a serial line just to move a cursor past the rightmost column in 2003 :) also, i assume: ioctl.h struct winsize, and termios.h struct termios are available in one form or another on most platforms? is the RAW termios state a cross-platform state? or is it a BSD specific state? thank you (please ditto any replies off-list). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vt/ansi codes
http://www.freebsd.org/mailto.html Questions regarding FreeBSD should be addressed to the FreeBSD Questions mailing list, [EMAIL PROTECTED] Mailing lists are the primary support channel for FreeBSD users, with numerous mailing lists covering different topic areas. Several non-English mailing lists are also available. the basis for this question was to determine if it was feasible to write a portable FBSD application and/or library without external dependencies. it is understood what ncurses and SLang are for - and initially ANSI escape sequences seemed to provide a way to break through the burdens and complications of ncurses and termcap entries. and in learning a bit about terminal I/O, questions regarding FreeBSD came to mind. -- the way things are, based on pcvt(4) and xterm(1), is that FreeBSD (and XFree86) implements vt220 (and vt102) emulation as the main terminal I/O driver. i fail to see the intelligence of implementing terminal drivers that are based upon 25 year old antiquated commercial terminals and their associated proprietary and deficient command sets, thereby forcing the use of special library dependencies containing various optimization hacks to work around such deficiencies. wouldn't it be much more intelligent/efficient/effective to implement non-commercial universal escape sequence standards that are more functional (such as 1979 ANSI 3.64) thereby eliminating the need for special library dependencies with regard to terminal I/O apps; reserving such library dependency usage for terminals that need such hacks due to their proprietary/limited command sets? i mean - why dumb down FBSD on a PC to the level of a antiquated proprietary terminal command set, and ineffectively force the use of oft broken inefficient hacks in library dependencies to make up for the deficiencies? why not smarten FBSD (and XFree86/xterm) terminal I/O to use more universal escape sequence standards that take better advantage of PC capabilities, and relegate usage of ncurses/termcap and the like to those programs requiring specialized hacks to run on proprietary hardware/terminals? why not shift the focus of terminal I/O to better suited universal standards, instead of a 25 year old proprietary and limited command sets. i think this would result in much greater all-around productivity. Chris i am trying to develop terminal I/O based code, and found myself meandering down a path to acquire terminal knowledge (i don't need to be told of SLang/ncurses/...). I wonder with this is really relavent to FreeBSD questions. But in any case here is my 2 cents worth. Have you looked at termcap and terminfo, which of course underpin curses/ncurses. It doesn't really matter what standards might be defined; the important issue is what functions commonly available terminals and terminal emulations have. There are an enormous variety of terminals and terminal emulations which have very little in the way of a common subset of functions. If you must use one common subset then you had best stick to VT100, I guess that will get you into between 1/3 and 2/3 of the terminals and emulations out there. Unix and same other OS have dealt with the problem by using databases of terminal information - termcap and/or terminfo - so that terminals with different control sequences can be managed by the same software and the software doesn't need prior knowledge of the specific control codes. In 1979 to send a full screen of say 2000 characters took perhaps 1 to 5 minutes, now in a similar situation we commonly send that in 20 to 100 milliseconds so the problem of dealing with different standards is largely circumvented by using less in the way of fancy functions and instead just redrawing the screen. Now-a-days graphic displays generally get more attention (not that I think this is necessarily good) and means of updating these with respect to the available bandwidth is receiving considerable attention. Malcolm Kay UNIX is designed not to rely on one single terminal type. IMO, tailoring writing your application so it can only run on vt100 terminals (or ansi terminals, if you had your wish) is misguided..use one of the character display libraries that handle all the internal details in a terminal-independent way. Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
is this a FBSD printf bug?
FBSD 4.8
i hope this isn't a question based on extreme
ignorance - i haven't programmed in C in a
long time, and i don't have another machine
to test this on. i can't understand why
the output of the following code produces
ints when given variables of type char,
so it looks like a bug to me ...
#include stdio.h
///
int main(int argc, char *argv[]) {
#define LEN_ARRAY 16
char a[LEN_ARRAY+1];
int i;
a[0]=0x00;
a[1]=0x11;
a[2]=0x22;
a[3]=0x33;
a[4]=0x44;
a[5]=0x55;
a[6]=0x66;
a[7]=0x77;
a[8]=0x88;
a[9]=0x99;
a[10]=0xaa;
a[11]=0xbb;
a[12]=0xcc;
a[13]=0xdd;
a[14]=0xee;
a[15]=0xff;
for ( i = 0; i LEN_ARRAY; ++i ) printf([%02i]%02x\n, i, a[i]);
}
///
//
// OUTPUT:
//
// [00]00
// [01]11
// [02]22
// [03]33
// [04]44
// [05]55
// [06]66
// [07]77
// [08]ff88 ???
// [09]ff99 ???
// [10]ffaa ???
// [11]ffbb ???
// [12]ffcc ???
// [13]ffdd ???
// [14]ffee ???
// [15] ???
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: where packets are dropped in route
Maybe your ISP is blocking port 22 after all. nmap will tell you. can nmap (which i don't have installed) tell me more than telnet - as far as a where a specific IP/port packet is being blocked/dropped? If you mean where along the path it is getting dropped, no. Other than what you have tried so far with traceroute, I don't believe there is really any way to tell WHERE certain ports are being dropped. For all you know, there could be a transparent firewall that drops the packet and does not send back an ICMP notification. Hope this helps. to finish the thread nicely, this is the result of nmap (-P0 required): $ nmap -p 22 -P0 -sA MY-GW-IP Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on (MY-GW-IP): Port State Service 22/tcp filteredssh Nmap run completed -- 1 IP address (1 host up) scanned in 36 seconds $ nmap -p 22 -P0 -sW MY-GW-IP Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on (MY-GW-IP): Port State Service 22/tcp filteredssh Nmap run completed -- 1 IP address (1 host up) scanned in 37 seconds --- filtered means that nmap(1) cannot determine if a port is open or closed - because it can't reach it, the traceroute(8) utility confirms (i guess): --- $ traceroute -p 22 -P tcp 12.17.140.247 1 1-118-237-24 (24.237.118.1) 150.900 ms 226.750 ms 99.080 ms 2 177-48-96-206 (206.96.48.177) 109.873 ms 118.265 ms 109.982 ms 3 81-128-165-209 (209.165.128.81) 129.754 ms 108.081 ms 129.900 ms 4 9-128-165-209 (209.165.128.9) 99.918 ms 108.252 ms * 5 202-129-165-209 (209.165.129.202) 140.307 ms 128.159 ms 129.912 ms 6 213-129-165-209 (209.165.129.213) 129.899 ms 128.249 ms 129.883 ms 7 sl-gw11-sea-0-2.sprintlink.net (144.228.93.233) 129.916 ms 247.420 ms 119.160 ms 8 sl-bb21-sea-9-3.sprintlink.net (144.232.6.117) 129.923 ms 129.112 ms 129.866 ms 9 sprint-gw.st6wa.ip.att.net (192.205.32.173) 129.941 ms 236.239 ms 129.925 ms 10 gbr4-p40.st6wa.ip.att.net (12.123.44.134) 129.878 ms 276.170 ms 129.826 ms 11 gbr1-p40.st6wa.ip.att.net (12.122.5.162) 129.890 ms 128.086 ms 129.896 ms 12 gar1-p360.st6wa.ip.att.net (12.123.44.58) 139.894 ms 128.144 ms 129.860 ms 13 12.123.203.1 (12.123.203.1) 159.911 ms 159.252 ms 159.929 ms 14 12.124.174.58 (12.124.174.58) 159.894 ms 179.251 ms 189.900 ms 15 12.17.140.1 159.916 ms 219.640 ms 169.925 ms 16 * * * ** TCP SSH port blocked by 12.17.140.1 $ traceroute -p 22 -P udp 12.17.140.247 1 1-118-237-24 (24.237.118.1) 140.974 ms 96.948 ms 109.883 ms 2 177-48-96-206 (206.96.48.177) 99.909 ms 108.272 ms 100.431 ms 3 81-128-165-209 (209.165.128.81) 109.347 ms 98.296 ms 99.874 ms 4 9-128-165-209 (209.165.128.9) 99.923 ms 98.214 ms 99.894 ms 5 202-129-165-209 (209.165.129.202) 129.904 ms 128.249 ms 130.284 ms 6 * * 213-129-165-209 (209.165.129.213) 130.333 ms 7 sl-gw11-sea-0-2.sprintlink.net (144.228.93.233) 128.730 ms 127.648 ms 129.876 ms 8 sl-bb21-sea-9-3.sprintlink.net (144.232.6.117) 129.907 ms 128.742 ms 129.378 ms 9 * sprint-gw.st6wa.ip.att.net (192.205.32.173) 180.893 ms 127.553 ms 10 gbr4-p40.st6wa.ip.att.net (12.123.44.134) 129.917 ms 127.873 ms 130.271 ms 11 gbr1-p40.st6wa.ip.att.net (12.122.5.162) 129.555 ms 128.079 ms 130.012 ms 12 gar1-p360.st6wa.ip.att.net (12.123.44.58) 130.377 ms 127.471 ms 129.905 ms 13 12.123.203.1 (12.123.203.1) 159.890 ms 158.353 ms 180.235 ms 14 12.124.174.58 (12.124.174.58) 329.566 ms 198.359 ms 219.902 ms 15 12.17.140.1 170.460 ms 169.097 ms 159.951 ms 16 MY-GW-IP 339.902 ms 329.998 ms 259.590 ms ** UDP SSH port available (but a UDP connection is useless on port 22). --- thank you all for your assistance and knowledge. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: where packets are dropped in route
Maybe your ISP is blocking port 22 after all. nmap will tell you. -mackan can nmap (which i don't have installed) tell me more than telnet - as far as a where a specific IP/port packet is being blocked/dropped? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
cd *
FBSD-4.7R on other BSD's, and with ftp(1), 'cd x*' will cd to the 1st match. FBSD used to work this way as well a few minor versions ago. these days it crashes with 'too many arguments' if there is more than one match. i 'object' to this behavior :) i would like to report it as a bug ... is there a good reason for it's current behavior? Thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
the method used by FBSD 2.2.7 seems the most sane to me, where execve's argv[] is loaded by each whitespace seperated element after the shebang, then by command line options. 1. it is flexible. 2. it functions intuitively. 3. i don't think it breaks less flexible methods. It also suffers from problems with arguments that are meant to include spaces, like: #!/bin/sh hello world foo bar Without a fully functional sh(1)-like parser, any solution that does magic with argv[] is incomplete :-( Apologies for a delayed response. This concerned how to load execve()'s argv[] array when parsing the 'shebang' line of a script, ie: whether to pass everything after '#!/interpeter' 1. as one string into execve()'s argv[] array, as some systems do, or 2. as individual arguments, as exist after #!/interpreter, separated by whitespace. Bug report 16383 showed the variance in the various UNIX's of how this is done. Orginal SysV specs say to load '1 argument' only after #!/interpreter, leaving it ambiguous as to whether the '1 argument' is the 1st whitespace separated argument, or whether it is everything after #!/interpreter as one string. Posix and SUSv3 don't say anything about how to load execve()'s argv[] array after #!/interpreter, and seem to leave it to whatever is the most intelligent way. I suggested it made more sense as FBSD 2.2.7 used to do it, where execve()'s argv[] array was loaded contiguously with whitespace separated elements, so one could use constructs such as #!/bin/sh /script-preprocessor options, and to allow #!/interpreter opt1 opt2 and #!/interpreter opt1 arg1 type constructs, things that intuitively work as one would expect on a command line, since there didn't appear to be any penalty for allowing this flexibility. A plausible argument was given in response: #!/bin/sh hello world foo bar I repond as follows: that's something only a Windoze user would think of doing! :) Unix users don't put whitespace in filenames, nor would they create options to programs that contain whitespace. Also, to load: 'hello world foo bar' as one string, breaks it's purpose anyway. it is a bizarre example that has little practical value, and can be easily compensated for by getting rid of whitespace in a filename, in the bizarre case where it may exist as such. Finally, to be slightly extreme with a tiny performance penalty, a beginning and ending quote in a string could be check for and respected by execve()'s code that fills argv[]. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
it seems more sane to allow arguments to a script given to an interpreter on the shebang line, passing everything after #!/interpreter [arg] off for eval or sh -c type parsing. This is something that can be bth good and bad though. As you have pointed out, if a limited sort of parsing is allowed, then it would most likely have to be sh(1)-like. This means that the mechanism that inteprets '#!' would have to know all the intricacies of the sh(1) parser to work correctly in all cases. Incomplete sh(1)-like parsers that would understand most of the sh(1) shell syntax would be exactly that... incomplete. the method used by FBSD 2.2.7 seems the most sane to me, where execve's argv[] is loaded by each whitespace seperated element after the shebang, then by command line options. 1. it is flexible. 2. it functions intuitively. 3. i don't think it breaks less flexible methods. i thank you very much for explaining this to me. Another bad thing about this is that you would then need a lot more memory to handle things like: #!/bin/sh -c \ 'my-magic-script.sh arg1 arg2 \ arg3 ...' \ `backquoted command` I'm not objecting to something like this. If you happen to roll patches for the kernel that can make it work, I'll probably try them too. But are the benefits of writing something like this worth the time required to write and test it? i agree. my main problem, which doesn't exist with FBSD (thankfully), was, for example, scriptA --- #!/bin/sh ./scriptB 1 2 3 where scriptB runs (with options), then processes scriptA, then exec's scriptA with a modified command line. (it would've been a long chore to write scriptB in C code, and it would've been a kludge to run scriptB on the command line with scriptA as an argument - forcing one to always type 2 words to do one command). many OS's do not allow this since they load ./scriptB 1 2 3 into a single argv[] element, which, of course, the interpreter cannot run. which seemed very stupid to me. i saw problems and limitations, and no benefit to that solution. There is one portable way. It's easy to remember too: #!/bin/sh No spaces, no args. It works so far on all the systems I've tried. heh - yes - i agree. i was afraid someone would pick apart all this! i didn't really take the time to study the functionality of the sh(1) options. i only meant to show the unintuitive nature of the implimentations with regard to parsing. #!/bin/sh scriptthis is obviously ok. #!/bin/sh . script this won't work if script is going to do something before exec'ing the file itself. it will end up being infinitely recursive. and similarly for the following: #!/bin/sh -n script this is currently not ok but why shouldn't it be? #!/bin/sh exec /bin/sh -n script #!/bin/sh script 1 2this is ok with FBSD and RH Linux, but not ok in a few implementations, but why shouldn't it be? #!/bin/sh exec /bin/sh script 1 2 The only objection I have in making execve() behave as if the whole she-bang thing was a valid sh(1) command, is that I don't want sh(1) being imported into the kernel tree, period. Of course, what I want is irrelevant if someone comes up with a solution to the problem of having an sh(1)-like parser without having sh(1) in the kernel :-) yes - i agree. i think freebsd hackers are the best. and have the best design/implementation philosophies. i am always humbled in their presence. - Giorgos thank you. Freebsd seems to be the only intelligent OS. 2.2.7, imho, seems to be correct. it may not follow, but sometimes intelligence has to lead ... I would be interested in anyone could tell me how/why any of the other solutions are more intelligent/practical. It is my personal observation the solutions of most vendors is due to SysV's limiting definition of execve(2). But I did note that Posix/SUSv3 definitions remove such arbitrary limitations (the single [arg]). #!/tmp/interp -a -b -c #d e Solaris 8: args: /tmp/interp -a/tmp/x2 Tru64 4.0: args: interp -a -b -c #d e /tmp/x2 *FreeBSD 2.2.7: args: /tmp/interp -a -b -c #d e /tmp/x2 FreeBSD 4.0: args: /tmp/interp -a -b -c /tmp/x2 Linux 2.4.12: args: /tmp/interp -a -b -c #d e /tmp/x2 Linux 2.2.19: args: interp -a -b -c #d e /tmp/x2 Irix 6.5: args: /tmp/interp -a -b -c #d e /tmp/x2 HPUX 11.00:args: /tmp/x2 -a -b -c #d e /tmp/x2 AIX 4.3: args: interp -a -b -c #d e /tmp/x2 Mac OX X: args: interp -a -b -c #d e /tmp/x2 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
minor correction/addition to previous post: instead of infinitely recursive, i should've said that it would break things if script re-exec's the same file with a different interpreter. -- #!/bin/sh . script this won't work if script is going to do something before exec'ing the file itself. it will end up being infinitely recursive. and similarly for the following: #!/bin/sh -n script this is currently not ok but why shouldn't it be? #!/bin/sh exec /bin/sh -n script #!/bin/sh script 1 2this is ok with FBSD and RH Linux, but not ok in a few implementations, but why shouldn't it be? #!/bin/sh exec /bin/sh script 1 2 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
#!/bin/sh execve
say i have 2 scripts, scriptA and scriptB. scriptA --- #!/bin/sh ./scriptB 1 2 3 scriptB --- #!/bin/sh echo 0:$0 echo 1:$1 echo 2:$2 echo 3:$3 -- $ ./scriptA $0:./scriptB $1:1 $2:2 $3:3 -- according to execve(2), only a single [arg] should be recognized: #! interpreter [arg] When an interpreter file is execve'd, the system actually execve's the specified interpreter. If the optional arg is specified, it becomes the first argument to the interpreter, and the name of the originally execve'd file becomes the second argument; otherwise, the name of the originally execve'd file becomes the first argument. The original argu- ments are shifted over to become the subsequent arguments. The zeroth argument is set to the specified interpreter. so the argv[] array in execve() should be loaded as: argv[0]=sh, argv[1]=scriptB, argv[2]=scriptA, and argv[3...]=command line args passed to scriptA. i read many many execve() man pages, and it seems like this is the way things should be. but in practice, it appears on many unix's, argv[] gets loaded additionally with any options given to a script (which is given as the [arg] to the interpreter) on the 1st line of a script. can anyone tell me if this is proper, and why or why not? there doesn't seem to be consistency across unix's. some ignore, or give an error if more than one [arg] exists on the 1st line of a script. thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
this does seem to be an ambiguous area. it seems more sane to allow arguments to a script given to an interpreter on the shebang line, passing everything after #!/interpreter [arg] off for eval or sh -c type parsing. i don't know how it breaks anything to load execve's argv[] with everything after the shebang, followed by command line options/args. but it sure muddies the water if you don't. otherwise there is a can of worms unnecessarily: #!/bin/sh -xthis is obviously ok. #!/bin/sh -vx this is obviously ok too. #!/bin/sh -cstringthis is currently not ok, but why shouldn't it be? #!/bin/sh -c string this is currently not ok, but why shouldn't it be? #!/bin/sh scriptthis is obviously ok. #!/bin/sh -n script this is currently not ok, but why shouldn't it be? #!/bin/sh script 1 2this is ok with FBSD and RH Linux, but not ok in a few implementations, but why shouldn't it be? it seems that only a minority of execve() man pages / implementations are preventing the sane solution ... The only thing I can find in IEEE Std 1003.1-2001 (aka SUSv3) is If the first line of a file of shell commands starts with the characters #!, the results are unspecified. which would indicate that there is no proper way of doing this. You may also want to have a look at bin/16393; at the bottom is a list of how some unices handle the situation. Your best bet at trying to be portable is to use at most one argument, no whitespace and no #. The PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=16393 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
^Z fg
FBSD 4.7R - the following appears to be different behavior than i have experienced in the past, and somewhat unusual. please reply off list as well if you reply. $ startx is the command above supposed to operate like ^Z (suspend)? i would not think so. i would think that such commands detach from the terminal and run in the background regardless of further commands in the foreground; however, following the command above with fg brings the process to the foreground, as if one had started a process in the foreground and suspended it with ^Z. is this a bug? thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
virtual window managers
i would like to know if there exists any fix for my problem here: problem: apps like XV and MPEG_PLAY refused to open dialogs/windows in any virtual window other than the one containing the origin in window managers that support them (VTWM in my case). this really sucks, since one is forced to always remain in the virtual window #1 when using these apps (there's probably more) or any apps that call on these apps - which destroys the whole purpose of having a virtual window type window manager. from what i understand, it's due to incorrect function calls by these apps, and this appears to be a long standing problem, since it is documented in 6+ year old documentation. i guess i am wondering why this stuff has never been fixed by the authors of these apps, or anyone else - or if their is a solution i am unaware of ... thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: mass storage
the umass(4) drivers work perfectly for me and my digital camera and smartmedia cardreader. what isn't working for you? -Adam i had an Olympus D-150, it only worked once per boot/mount (would not mount after a umount unless kernel was rebooted), currently i have a Toshiba PDR-M25, which claims to be USB auto connect and Universal Mass Storage compatible as well: [i would be happy to provide additional info if i can be of better assistance to any umass developers ...] scsi_da.c - default: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.6-RELEASE #1: Thu Jan 1 06:19:46 AKST 1998 Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 167046230 Hz CPU: Cyrix 6x86MX (167.05-MHz 686-class CPU) Origin = CyrixInstead Id = 0x600 Stepping = 0 DIR=0x0752 Features=0x80a135FPU,DE,TSC,MSR,CX8,PGE,CMOV,MMX real memory = 33554432 (32768K bytes) avail memory = 29736960 (29040K bytes) Preloaded elf kernel kernel at 0xc0309000. Preloaded userconfig_script /boot/kernel.conf at 0xc030909c. Using $PIR table, 6 entries at 0xc00fd980 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller at device 7.1 on pci0 atapci0: ATA channel disabled by BIOS pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 irq 15 chip1: Intel 82371AB Power management controller port 0x5000-0x500f at device 7.3 on pci0 atapci1: Promise ATA100 controller port 0x7800-0x783f,0x7400-0x7403,0x7000-0x7007,0x6c00-0x6c03,0x6800-0x6807 mem 0xe400-0xe401 irq 11 at device 17.0 on pci0 ata2: at 0x6800 on atapci1 ata3: at 0x7000 on atapci1 ohci0: OPTi 82C861 (FireLink) USB controller mem 0xe402-0xe4020fff irq 10 at device 18.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: OPTi 82C861 (FireLink) USB controller on ohci0 usb0: USB revision 1.0 uhub0: OPTi OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered umass0: Toshiba PDR-M25, rev 1.10/1.00, addr 2 pci0: S3 968 graphics accelerator at 19.0 irq 12 orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc9fff on isa0 sc0: System console on isa0 sc0: VGA 9 virtual consoles, flags=0x200 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A ed0 at port 0x340-0x35f irq 5 on isa0 ed0: address 00:40:33:3b:d9:77, type NE2000 (16 bit) fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ad4: DMA limited to UDMA33, non-ATA66 cable or device ad4: 38166MB WDC WD400AB-22CDB0 [77545/16/63] at ata2-master UDMA33 acd0: CDROM FX3400S at ata2-slave PIO4 umass0: BBB reset failed, STALLED age repeated 4 times Mounting root from ufs:/dev/ad4a da0 at umass-sim0 bus 0 target 0 lun 0 da0: TOSHIBA M25 1.00 Removable Direct Access SCSI-0 device da0: 650KB/s transfers da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) umass0: BBB reset failed, STALLED umass0: BBB reset failed, STALLED da0: reading primary partition table: error reading fsbn 0 umass0: BBB reset failed, STALLED (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x10, scsi status == 0x0 umass0: BBB reset failed, STALLED age repeated 2 times da0: reading primary partition table: error reading fsbn 0 umass0: BBB reset failed, STALLED (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x10, scsi status == 0x0 umass0: BBB reset failed, STALLED umass0: BBB reset failed, STALLED umass0: BBB reset failed, STALLED da0: reading primary partition table: error reading fsbn 0 umass0: BBB reset failed, STALLED (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x10, scsi status == 0x0 umass0: BBB reset failed, STALLED age repeated 2 times da0: reading primary partition table: error reading fsbn 0 umass0: BBB reset failed, STALLED (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x10, scsi status == 0x0 umass0: BBB reset failed, STALLED scsi_da.c - DA_Q_NO_SYNC_CACHE: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.6-RELEASE #3: Wed Sep 18 01:46:14 AKDT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/MYKERN Timecounter i8254 frequency 1193182
/dev/null and 2-
i just installed 4.6-RELEASE, and notice that the '2-' sh (FBSD) construct seems to be broken. i am going thru all my scripts having to change it to /dev/null ... i figure it's not realistic to assume a bug this obvious would make it to release stage, so my question is - is something else going on? or is this just due to changes in 'sh'? is it a bug? or is it a permenent change? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
