I realise this isn't a programming question but can anyone advise if it's possible to change the width of the printable line in the Pyscripter Interpreter?
Can't find anything in the documentation.
At the moment it prints 74 characters then wraps.
I realise this may seem trivial but when trying to view a pandas dataframe with 100+ lines the 'wrap' starts the end of the first line after its output the first 74 characters of the last line.
Related
Folks, I am having a text with one long line and need to justify it with specific width (I know fold can do this) but the needed output should be like a block which might needs to insert spaces between words like emacs, but I don't have emacs , so can you please advise on this?
Direct translation to the fold(1) command
fold --width=80 --spaces
This question already has answers here:
How to select lines between two marker patterns which may occur multiple times with awk/sed
(10 answers)
Closed 6 years ago.
There is some text I need from a web page, a page whose length changes somewhat from day to day. I am looking to download that text periodically. I do not want/need several dozen lines from both the beginning and end of the roughly 250 line page. The total number of lines on the page will be unpredictable, so I will be needing to establish beginning/end points for the deletion I wish to perform based on bits of text that do not change from day to day. I've identified the target text patterns, so I'm looking to parse the content based on those such that the unwanted lines get deleted in the resulting document. I'm wanting to use command line utilites for this since I would like to automate the process and make a cron job out of it.
The download method of choice is to use lynx -dump www.specified.url my-download.txt
That part is working fine. But processing the dump so as to cut off the unwanted beginning and ending lines is so far not working. I found a sed example that, it seems, should do what I need:
sed -n '/Phrase toward the beginning/,/Phrase toward the end/p' file_to_parse.txt >parsed_file.txt
It works partially, meaning it cuts off the file's beginning at the right point (all lines preceding "Phrase toward the beginning"). But I cannot seem to make it cut lines from the end, i.e., lines following the phrase "Phrase toward the end." All my attempts using this formula have so far not touched the end of the file at all. I should probably mention that most of the lines in the dumped file lynx produces begin, for whatever reason, with 3 blank spaces--including the "Phrase toward the end" line I'm trying to specify as the point after which further lines should be deleted.
I assume there may be more than one utility that can do the sort of parsing I'm after--sed and awk are the likely candidates I can think of. I tend to gravitate toward sed since its workings are slightly less mysterious to me than are awk's. But truth be told, I really only have the vaguest of conceptions as to how to use sed. When it comes to using and/or understanding awk, I get lost very, very quickly. Perhaps there are other utilities that can, based on textual patterns, lop off portions of the beginning and ending of a text file?
Input on how I might use sed, awk--or any other similar utility--to accomplish my goal, will be appreciated. This is to be done on an Ubuntu machine, btw.
LATER EDIT: sorry for not having posted and example. The downloaded page will look something like the following
Unwanted line 1
Unwanted line 2
Unwanted line 3
Unwanted line etc
Phrase toward the beginning
Wanted line 1
Wanted line 2
Wanted line 3
Wanted line ca 4-198
Phrase toward the end
Unwanted line 200
Unwanted line 201
Unwanted line 202
Unwanted line . . . (to end of file)
The final output should look, on the other hand, like
Phrase toward the beginning
Wanted line 1
Wanted line 2
Wanted line 3
Wanted line ca 4-198
Phrase toward the end
I hope things will be clearer now. Please do bear in mind, though I've used line numbers to help better illustrate what I'm aiming to do, that I will be unable to do the desired deletions based on line numbers owing to the unpredictable ways in which the page I'm downloading will be changing.
If sed seems too difficult to debug, consider a double grep; for example here we list numbers 1 to 250, then grep for 70, plus up to 1000 lines after that, then grep for 80, plus up to 1000 lines before that:
seq 250 | grep -A 1000 '^70$' | grep -B 1000 '^80$'
Output:
70
71
72
73
74
75
76
77
78
79
80
Since the maximum length of the input files is known, 1000 is a safe number for your data (but overkill for the above example).
Applied to the OP data, the example would become:
grep -A 1000 'Phrase toward the beginning' download_page.txt | \
grep -B 1000 'Phrase toward the end'
The debugging advantage over sed is that the error messages from grep are simpler than those from sed.
i was expecting this command
^FO15,240^BY3,2:1^BCN,100,Y,N,Y,^FD>:>842011118888^FS
to generate a
(420) 11118888
interpretation line, instead it generates
~n42011118888
anyone have idea how to generate the expected output?
TIA!
Joey
If the firmware is up to date, D mode can be used.
^BCo,h,f,g,e,m
^XA
^FO15,240
^BY3,2:1
^BCN,100,Y,N,Y,D
^FD(420)11118888^FS
^XZ
D = UCC/EAN Mode (x.11.x and newer firmware)
This allows dealing with UCC/EAN with and without chained
application identifiers. The code starts in the appropriate subset
followed by FNC1 to indicate a UCC/EAN 128 bar code. The printer
automatically strips out parentheses and spaces for encoding, but
prints them in the human-readable section. The printer automatically
determines if a check digit is required, calculate it, and print it.
Automatically sizes the human readable.
The ^BC command's "interpretation line" feature does not support auto-insertion of the parentheses. (I think it's safe to assume this is partly because it has no way of determining what your data identifier is by just looking at the data provided - it could be 420, could be 4, could be any other portion of the data starting from the first character.)
My recommendation is that you create a separate text field which handles the logic for the parentheses, and place it just above or below the barcode itself. This is the way I've always approached these in the past - I prefer this method because I have direct control over the font, font size, and formatting of the interpretation line.
Most modern programming languages give a way to add inline comments, generally those that use a newline character to indicate the end of a comment, and an arbitrary delimiter or sequence of tokens to indicate the beginning of a comment, while letting the beginning of the line being an interpreted instruction.
In COBOL, while commenting a whole line is well documented (it can be done by putting an asterisk symbol (*) in column 7), finding documentation on whether or not you can comment the rest of the line beginning at an arbitrary position is harder.
The question is: can you comment the rest of a line beginning at an arbitrary position in COBOL?
Imagining that # is the special character for this kind of comment, here is a fictive example of what is seeked:
*--- This structure is a dummy example
01 MY-STRUCTURE.
05 MY-VARIABLE PIC X VALUE '-'. # Valid values are in {-, a, b}
Pre Cobol 2002 No
In Cobol 2002 *> was introduced. see Cobol 2002 and search in-line comment, which give this example:
05 Field-X Pic XX *> Used in calculating the current THINGY
...
MOVE ABC to XYZ *> Current-XYZ
LMN *> Saved XYZ
There are other some exceptions
In Exec Sql - End-Exec. you are able to use in-line comments (/* */) for some SQL venders (e.g. Oracle). This is not true Cobol though but an embeded language, generally implemented via a pre-compiler. Othere Exec End-exec statement may also allow in-line comments.
There may be other Cobols implementations that allow in line comments
By default many pre Cobol 20002 compiler's only look at columns 7 to 72. So columns 1 to 6 and anything after column 71 can hold comments.
Enterprise COBOL V5.1 will support inline comments
From the Release Highlights
Introduces the floating comment indicator to create a comment anywhere
in the program-text area Enterprise COBOL for z/OS, V5.1 introduces
the floating comment indicator ('*>').
You can specify it anywhere in
the program-text area to indicate that the ensuing text on a line is a
comment line or an inline comment.
A floating comment indicator
indicates a comment line if it is the first character string in the
program-text area (Area A plus Area B, columns 8 - 72), or indicates
an inline comment if it is after one or more character strings in the
program-text area.
No, but you can write a program to "WRAP" your code when you submit it to the compiler. We did this 20 years ago.
for example.
SOME COBOL CODE -- DOUBLE DASH INDICATES COMMENT TO END OF LINE
THEN write a program that looks for the double dashes and have it delete the -- and the text.
Then in your compile jcl, input your source code to the program, and the output to the compiler. Simple. Use the INSPECT statement.
INSPECT LINE, TALLYING CHARACTERS BEFORE INITIAL "--".
MOVE SPACES TO LINE(TALLY:),
And that is it. Removes the comments and sends to compiler.
COBOL documentation. Open, free.
http://opencobol.add1tocobol.com/ OpenCOBOL FAQ and how-to.
http://opencobol.add1tocobol.com/OpenCOBOL%20Programmers%20Guide.pdf (Awesome)
And for a limited time, while it remains Draft and open for comment
http://www.cobolstandard.info/j4/files/std.zip
That last link is almost guaranteed to expire when the COBOL 20xx Draft becomes a ratified ISO Standard, and is not really for redistribution, other than from the ISO PL22 WG4 source.
COBOL supports FIXED and FREE source code formats. FIXED is older, based on 80 column cards, with columns one to six for sequence numbers, 7 for directives and columns 8 thru 72 for program text.
Asterisk in column 7 is a FIXED form COBOL comment line.
OCOBOL* Sequence number field "OCOBOL" in this case, it can be anything
* and comment line indicator
*> inline comment, can be used for FREE format COBOL, as well as FIXED.
There is a trick; place the asterisk in column 7 with the greater than symbol in column 8 and you have a comment line that works in both fixed and free format COBOL.
For compilers that will follow draft 20xx and
>>
directives, there is another trick to assist in FIXED/FREE source compile support.
123456
>>D free format debug line directives
if the D is in column 7, with the two greater thans in 5 and 6, you have mixed FIXED and FREE source text support for debug lines as well.
I have a line of Fortran code, which includes some text. I'm changing the text, which makes the code line too long for Fortran, so I split it over two lines using 'a'.
Was:
IF (MYVAR .EQ. 1) THEN
WRITE(iott,'(A) (A)') 'ABC=', SOMEVAR
Changed to:
IF (MYVAR .EQ. 1) THEN
WRITE(iott,'(A) (A)') 'ABC DEF GHI JK
a ' // 'L=', SOMEVAR
My question is, on the new line (starting with 'a'), does the white space between the 'a' and the first ' get appended to the string? Or do I need the ' to be the char next to a to prevent additional white space?
As you can tell, I'm not used to Fortran...
If you're worried about exceeding a 72 column limit, then I assume you're using Fortran 77. The syntax for Fortran 77 requires that you start with column 7, except for continued lines, which need a continuation character in column 6. I use the following method to tell me how many lines are continued for one statement (the first line is just to show the columns):
!234567890
write(*,*)"Lorem Ipsum",
1 " Foo",
2 " Bar"
This would print:
Lorem Ipsum Foo Bar
You don't have to worry about spaces that aren't in quotes. All whitespace gets compressed in Fortran, anyway.
It's worthwhile learning how to use format statements. They can make output a lot easier. It's somewhat similar to printf statements, if you're coming from C. You specify a format with different types of parameters, then give variables or literals to fill out that format.
And don't worry that you're not working with the hot, new, language of the day. You can learn a lot from Fortran, even Fortran 77, and when used properly, Fortran can even be elegant. I've seen Fortran 77 written as if it were an object oriented language, complete with dynamic memory. I like to say, "old.ne.bad".
It's been too long for me to remember the old column requirements of FORTRAN (and they may not even be as strict as they were way back when).
But - isn't this something that a quick test run will tell you straight off?
Yes, the a is a continuation character and basically it just means append the rest of this line starting after the continuation character (col 6, right?) to the previous line.
Your Fortran compiler probably has an option to turn on "free form" input instead of using "fixed form" input. Use this and you won't have to worry about line length.
If your Fortran compiler is older than F90 -- which is when I think the free form input ability started, you have my condolences.
#Mike B:
In an ideal world yes, but in this case the code is developed on one machine, and submitted to a build server which has the appropriate 3rd party software / SDK's / licenses available to it to build. The build isn't exactly quick either.