In fortran stderr is unit 0. Stdin is unit 5 and stdout is unit 6. This appears to be a cray decision as far as Google seems to indicate, but it is not clear why they chose so. Why not 1 and 2? What was the use of 1-4 on old fortran compilers that shifted stdin and out to 5 and 6?
According to this page (the "Professional Programmer's Guide to Fortran77" by Clive G. Page), units 5 and 6 are assigned to stdin and stdout, respectively, for backwards compatibility and that card-readers were typically connected to "unit 5" and line printers to "unit 6", quote:
In order to retain compatibility with Fortran66, many systems provide other pre-connected files. It used to be customary to have unit 5 connected to the card-reader, and unit 6 to the line printer. Other units were usually connected to disc files with appropriate names: thus unit 39 might be connected to a file called FTN039.DAT or even TAPE39.
Not that this gives any logic to why numbers 5 and 6 were chosen, but only some historical context. Still leaves open what was connected to unit numbers 1-4 on historic machines. The following old books/handbooks might shed some light:
According to D.D. Fisher et al. An Introduction to Fortran Programming, page 90, not all FORTRAN compilers used units 5 and 6 for card-reader input and line printer output:
Waterloo FORTRAN IV and IBM System/360 FORTRAN IV did use units 5 and 6 for that purpose, on the IBM 1130, however, units 2 and 1 were used for card-reader input and line printer output.
And finally according to the FORTRAN-10/20 and VAX FORTRAN Compatibility Manual, page 3-6, in case of FORTRAN-10/20 "unit 1 is disk, unit 2 is the card reader, unit 3 is line printer, unit 5 is the terminal". With VAX FORTRAN, unit 5 is good for both I and O with the terminal.
Maybe this final part indicates that because some machines started to have terminals for I/O in addition to card-reader input and line printer output, and the preferred/default devices might have become terminals for both input and output, that the higher terminal-related units have become I/O defaults.
Related
I am developing a terminal TUI application for myself using the ncurses library. (Running on Linux)
I cannot seem to find much info regarding the use of a "strikethrough/strikeout" text attribute when adding a string to a ncurses window using addstr and friends.
The only information I've found online was on this site:
https://midnight-commander.org/ticket/3264
Ncurses will not add [strikethrough text] because the bitfield is already fully packed.
I was wondering if there are any workarounds to this, or any official way to do this.
Any help would be appreciated.
Thanks.
ncurses has 16 bits allocated for video-attributes. SVr4 curses used 8; XOpen Curses added 7. Those 15 are defined for X/Open Curses compatibility.
Referring to the X/Open Curses documentation, there are two sets of definitions:
A_ALTCHARSET Alternate character set
A_BLINK Blinking
A_BOLD Extra bright or bold
A_DIM Half bright
A_INVIS Invisible
A_PROTECT Protected
A_REVERSE Reverse video
A_STANDOUT Best highlighting mode of the terminal
A_UNDERLINE Underlining
and
WA_ALTCHARSET Alternate character set
WA_BLINK Blinking
WA_BOLD Extra bright or bold
WA_DIM Half bright
WA_HORIZONTAL Horizontal highlight
WA_INVIS Invisible
WA_LEFT Left highlight
WA_LOW Low highlight
WA_PROTECT Protected
WA_REVERSE Reverse video
WA_RIGHT Right highlight
WA_STANDOUT Best highlighting mode of the terminal
WA_TOP Top highlight
WA_UNDERLINE Underlining
WA_VERTICAL Vertical highlight
depending on whether the bits are stored in a attr_t or a chtype (X/Open and SVr4 respectively). In ncurses, those are the same (see the manual page), so that it does not matter if one refers to A_BOLD or WA_BOLD (Solaris xpg4 curses does store those differently).
Discounting the A_ vs WA_, the two lists are different. The newer ones from X/Open Curses are rarely used. Since ncurses doesn't know what it looks like on the screen, someone could add the corresponding terminfo capability to a terminal description and ncurses would handle it.
The terminfo manual page mentions these:
The XSI Curses standard added these hardcopy capabilities. They were
used in some post-4.1 versions of System V curses, e.g., Solaris 2.5
and IRIX 6.x. Except for YI, the ncurses termcap names for them are
invented. According to the XSI Curses standard, they have no termcap
names. If your compiled terminfo entries use these, they may not be
binary-compatible with System V terminfo entries after SVr4.1; beware!
(Explaining how to modify a terminal description can be found in thousands of webpages, and is off-topic for this forum).
Possible attributes in ncurses are:
A_NORMAL Normal display (no highlight)
A_STANDOUT Best highlighting mode of the terminal.
A_UNDERLINE Underlining
A_REVERSE Reverse video
A_BLINK Blinking
A_DIM Half bright
A_BOLD Extra bright or bold
A_PROTECT Protected mode
A_INVIS Invisible or blank mode
A_ALTCHARSET Alternate character set
A_CHARTEXT Bit−mask to extract a character
COLOR_PAIR(n) Color−pair number n
Functions like attron(), attroff(), attrset() may be used to work with attributes,
Strikethrough is not and will not be available.
If you know your terminal and want your software to be able to to work just on such an terminal type AND the terminal supports strikethrough, then you can use control characters or escape sequences to activate such a funcionality.
You can use Unicode for that:
(I know it's an old question, but I had a similar issue, and this is the top result for "curses strikethrough" on Google, so this answer might be helpful to someone.)
I made it work using Python, but the strategy should work in any language:
import curses
def strike(text: str) -> str:
# See <https://stackoverflow.com/a/25244576/4039050>
return "\u0336".join(text) + "\u0336"
def main(stdscr):
message = "The quick brown fox jumps over the lazy dog."
stdscr.addstr(strike(message))
stdscr.refresh()
stdscr.getch()
if __name__ == "__main__":
curses.wrapper(main)
By setting export GFORTRAN_STDOUT_UNIT=777 I want to change my stdout in gfortran. If I run the program
program main
implicit none
write (*,*) "*"
write (6,*) "6"
write (777,*) "777"
end program main
it will output
> $ ./a.out
777
and create a file:
> $ cat fort.6
*
6
Why isn't * forwarded to the stdout (now 777) anymore? Is this a gfortran bug or intended behaviour?
I believe the behaviour is as expected. The following paragraphs are of interest here:
GFORTRAN_STDOUT_UNIT: Unit number for standard output
This environment variable can be used to select the unit number preconnected to standard output. This must be a positive integer. The default value is 6.
source: GCC Gfortran Documentation
So this just states that /dev/stdout will be connected to the unit number GFORTRAN_STDOUT_UNIT.
The Fortran Standard makes the following statements:
9.5 File connection
9.5.1 Referring to a file
4 In a WRITE statement, an io-unit that is an asterisk identifies an external unit that is preconnected for sequential formatted output. This unit is also
identified by the value of the named constant OUTPUT_UNIT of the intrinsic module ISO_FORTRAN_ENV.
Note 9.15: Even though OUTPUT_UNIT is connected to a separate file on each image, it is expected that the processor could merge the sequences of records from these files into a single sequence of records that is sent to the
physical device associated with this unit, such as the user’s terminal.
source: Fortran 2008 Standard
All we know is that <asterisk> (ergo OUTPUT_UNIT) are preconnected to a unit for sequential formatted output. The standard makes no statement what this external unit is. It makes no reference to /dev/stdout. The standard actually explicitly mentions in a note that the user's terminal is a possible pre-connected unit, it could as well have been your printer.
So in the end, by setting GFORTRAN_STDOUT_UNIT=777, you just preconnect unit 777 to /dev/stdout and <asterisk> will be preconnected to an external unit for sequential output (i.e. in this case fort.6)
If I had an old PC game that has certain variables that cannot exceed 255 without crashing, would it be possible to convert ALL 8bit integers into 16bit integers by modifying the Windows 95 executable?
The game I'm talking about is Total Annihilation from 1997. And although the game itself was way ahead of it's time and had the capabilities to be modded into epic experiences, (Hell, the game was so ahead of it's time, the data files use JSON-like syntax... The game also supports 4K and looks amazing still.) there is unfortunately a limit to the total number of weapons in the game. All weapons have IDs, and the max ID of a weapon is 255 as can be seen below:
[NUCLEAR_MISSILE]
{
ID=122;
name=Nuclear Missile;
rendertype=1;
lineofsight=1;
vlaunch=1;
model=ballmiss;
range=32000;
reloadtime=180;
noautorange=1;
weapontimer=5;
flighttime=400;
weaponvelocity=350;
weaponacceleration=50;
turnrate=32768;
areaofeffect=512;
edgeeffectiveness=0.25;
energypershot=180000;
metalpershot=2000;
stockpile=1;
targetable=1;
commandfire=1;
cruise=1;
soundstart=misicbm1;
soundhit=xplomed4;
firestarter=100;
smokedelay=.1;
selfprop=1;
smoketrail=1;
propeller=1;
twophase=1;
guidance=1;
tolerance=4000;
shakemagnitude=24;
shakeduration=1.5;
explosiongaf=commboom;
explosionart=commboom;
waterexplosiongaf=fx;
waterexplosionart=h2oboom2;
lavaexplosiongaf=fx;
lavaexplosionart=lavasplashlg;
startsmoke=1;
[DAMAGE]
{
default=5500;
ARMCOM=2900;
CORCOM=2900;
}
}
Would this be worth it at all to attempt? I'm not very familiar with Assembly language, but I've heard that with C++ you sometimes have to write your own assembly language in certain instances back in the day.
All I want to do is just bump up all 8bit Ints to 16bit by editing the .EXE, how difficult would this be to pull off?
All I want to do is just bump up all 8bit Ints to 16bit by editing the .EXE, how difficult would this be to pull off?
Essentially impossible without access to the source code. Replacing an 8-bit integer with a 16-bit one would change the size and layout of the data structure which contained it. Any code which "touched" those objects, or any objects which contained them, would need to be updated. Identifying that code would be an extensive project -- in all probability, it'd require most of the game to be manually decompiled to C source code.
I have a file,namedtest.txt
182.7 100.0
182.6 100.0
182.8 100.0
I want to sure weather the line ends with the digits 100.0:
So I use the following code:
for line in open('test.txt','rt'):
print repr(line),line.endswith('100.0\n')
print
But the Output in Ubuntu is:
'182.7 100.0\r\n' False
'182.6 100.0\r\n' False
'182.8 100.0' False
But the Output in windows server 2008 is:
'182.7 100.0\n' True
'182.6 100.0\n' True
'182.8 100.0' False
I already using rt in open function,so why there is difference between different systems yet?
The function strip() can take care of the ending new line character, and it is independent of the operating system used, the code can be
print "{line} {expr}".format(line=repr(line), expr=line.rstrip().endswith('100.0'))
Thanks! Is the answer obvious now? The file was created on Windows, where lines end with "\r\n", not with "\n". So long as you read the file on Windows in text mode, Python can hide that from you. But you read the file on Linux, where the distinction between "text" and "binary" modes doesn't exist, and you get exactly whatever bytes are in the file.
My advice is to force line ends to the native convention on whatever platform you move files to. Short of that, in Python 2 you can open files in "universal newline mode" instead, as briefly explained here.
I'm trying to print Code 128 C type barcode (as type A/B would be too wide for my requirements) through Epson TM-H6000III receipt printer using OPOS Common Controls 1.8. My code is written in C++.
Normally, I print the barcode using the following code snippet:
const LONG PTR_BCS_Code128 = 110;
lOposBarcodeType = PTR_BCS_Code128;
lReturn = m_PosPrinter.PrintBarCode(2,*lpszTextline,lOposBarcodeType,120,5,PTR_BC_CENTER,PTR_BC_TEXT_BELOW);
Here, *lpszTextline represents the data to be printed as barcode.
From suggestions found online, I tried to make the following changes to print the barcode in Code 128 C format:
const LONG PTR_BCS_Code128_Parsed = 123;
lOposBarcodeType = PTR_BCS_Code128_Parsed;
lReturn = m_PosPrinter.PrintBarCode(2,*lpszTextline,lOposBarcodeType,120,5,PTR_BC_CENTER,PTR_BC_TEXT_BELOW);
and tried to format the barcode data in various ways:
Leading "{C"
Leading "{C", trailing "H"
Making no. of characters in the data even
But none of the ways worked. It always resulted in OPOS_E_ILLEGAL error with ResultCodeExtended = 300003. I cannot find more information about the extended code in the Internet either.
Any help in this regard will be highly appreciated.
Thanks in advance.
Prosu
The mode is often determined by the printer firmware, based on the data you are trying to print. The best behavior is when it tries to print as compact as possible: mode C is used if the data is all numeric, mode A is used if it's alphabetic, etc., and it switches from mode to mode as needed: a 17 digit number might print as mode C for the first 16 digits, then switch to mode A for the 17th digit.
If your printer firmware handles this directly, you may not even be able to choose the mode yourself. Alternately, some thermal printers cannot print anything but mode C and will return an error if you try to print alphabetic characters. (We had some old IBM Suremark printers that could only print mode C.)
You should check with Epson.