Sorry, new to this so hopefully I can explain it well enough
Using below example of text I need regex to find the line number after the FREE TEXT-ID line.
I then need to find the final line number of ANY of the lines.
This will need to be two separate regex codes as I need use each result in different places.
So using this example regex needs to locate 3 & 33.
HELP please! Many thanks
DOCI-AC ACCT-7XV.1C54071
2. FREE TEXT-ID/381920/61668/C54071-MITCHELL/DANIELMR
**3**. AGT INF-A5
4. FREE TEXT-RC/*1/01
5. FREE TEXT-BA/*1/A5
6. FREE TEXT-TA/*1/A5
7. FREE TEXT-FF6/*1/1
8. FREE TEXT-FF63/*1/0
9. FREE TEXT-FF9/*1/10-AUG-2020
10. FREE TEXT-FF12/*1/DANIEL MITCHELL
11. FREE TEXT-FF60/*1/3
12. FREE TEXT-FF61/*1/0
13. FREE TEXT-EC/*1/101
14. FREE TEXT-RF/*1/350.00
15. FREE TEXT-LF/*1/318.00
16. FREE TEXT-FF95/*1/LOWEST FARE ACCEPTED
17. FREE TEXT-SF/*1/340.00
18. FREE TEXT-MS/*1/PC39/V1TFEE/CP100/A20.00
19. FREE TEXT-RC/*2/03
20. FREE TEXT-BA/*2/A5
21. FREE TEXT-TA/*2/A5
22. FREE TEXT-FF6/*2/2
23. FREE TEXT-FF63/*2/0
24. FREE TEXT-FF9/*2/10-AUG-2020
25. FREE TEXT-FF12/*2/DANIEL MITCHELL
26. FREE TEXT-FF60/*2/3
27. FREE TEXT-FF61/*2/0
28. FREE TEXT-EC/*2/140*
29. FREE TEXT-RF/*2/1500.00
30. FREE TEXT-LF/*2/950.00
31. FREE TEXT-FF95/*2/LOWEST FARE ACCEPTED
32. FREE TEXT-SF/*2/950.00
**33**. FREE TEXT-MS/*2/PC39/V1TFEE/CP100/A40.00
>
Related
I am using Mosek in Matlab and I would like to suppress any printing after running an optimisation problem.
I have set param.MSK_IPAR_LOG = 0;. However, I still get the following message printed.
MOSEK Version 9.2.3 (Build date: ...)
Copyright (c) MOSEK ApS, Denmark. WWW: mosek.com
Platform: ...
How can I remove it?
Use echo(0) every time you run mosekopt, for example mosekopt('minimize echo(0)', prob, param) and so on.
https://docs.mosek.com/9.2/toolbox/solver-io.html
A work-around is to count how many characters it displays and then remove those characters.
fprintf(repmat('\b',1,n));
%where n is the number of characters to remove
This doesn't suppress the printing but it removes the printed characters instead.
I would like to refer to a few of Alan Perlis' Epigrams on Programming by their original numbers, but in an Org Mode ordered list.
When I export my document, the numbers I provide for the list items are discarded and replaced with new numbers, beginning with 1.
The raw source text:
#+begin_example
A few of Alan J. Perlis\rsquo{} [[http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html][Epigrams on Programming]]:
8. A programming language is low level when its programs require attention to the irrelevant.
15. Everything should be built top-down, except the first time.
31. Simplicity does not precede complexity, but follows it.
54. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.
#+end_example
The text as rendered, and renumbered, by export:
#begin_quote
A few of Alan J. Perlis\rsquo{} [[http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html][Epigrams on Programming]]:
8. A programming language is low level when its programs require attention to the irrelevant.
15. Everything should be built top-down, except the first time.
31. Simplicity does not precede complexity, but follows it.
54. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.
#end_quote
You can set the item number to whatever you want by beginning the text of the item with [#8] (for example). See Ordered List here.
A working example:
A list with custom ordering:
1. [#8] apple
1. [#77] orange
1. [#101] lime
When you export the document the list numbers will be 8, 77, and 101.
I'm trying to disassemble a BIOS image for the 68000, and I'm having trouble getting IDA Pro 6.5 to correctly cross-reference addresses.
For those who aren't aware, the Motorola 68000 has a couple of interesting features/quirks related to addressing:
When given a 16-bit absolute address, the processor sign-extends it to 32 bits before dereferencing it.
The 68K uses a 24-bit address bus, so the high byte in a 32-bit address is ignored.
The original authors of this BIOS took advantage of these properties in a number of places to save a few bytes: for any address above 0xFF8000, it's possible to specify the address using only two bytes instead of four. For example, if I wanted to access the memory at address 0xFF9134:
lea (0x9134).w, a0
< sign extension >
lea (0xFFFF9134).l, a0
< discard high byte >
lea 0xFF9134, a0
The problem I'm running into is that IDA Pro is performing the sign extension, but then considers the entire 32-bit address instead of only the lower 24 bits. IDA ends up trying to cross-reference addresses that don't (or at least shouldn't) exist, and any segments/code/data I have in the 0xFF8000-0xFFFFFF address range get completely ignored.
I'm still new to IDA Pro, so I don't know if this would be solvable with a script, let alone how to write such a thing. Is there a way I can get the disassembler to correctly handle this dirty/clever addressing trick?
I have the same problem. My decision was to create custom_ana callback and then change every operand address as the following: op.add &= 0xFFFFFF.
But it is not so easy. Because you don't have fully recognized "cmd" at this moment, and you must prepare it by your own code.
I am doing a project on ISBN barcode scanning. I have tried many scanning applications but after scanning this barcode:
the app only gives me back the barcode 9780749423490.
But what I need to obtain is the ISBN code 0749423498 instead, as it is in the database of my library. Is there any method to get it?
Can anyone explain the difference between these two codes? Why is the barcode number and ISBN barcode number different? Is it the same for some books and different for some ? thanks!
It looks like the confusion is the difference between the "ISBN 10" and "ISBN 13" standards.
The ISBN Agency website FAQ says:
"Does the ISBN-13 have any meaning imbedded in the numbers?
The five parts of an ISBN are as follows:
1. The current ISBN-13 will be prefixed by "978"
2. Group or country identifier which identifies a national or geographic grouping of publishers
3. Publisher identifier which identifies a particular publisher within a group
4. Title identifier which identifies a particular title or edition of a title
5. Check digit is the single digit at the end of the ISBN which validates the ISBN"
So the 978 is clearly just filler. After that, the next 9 numbers are obviously the same in both numbers. The last digit in both numbers is a check digit, which is different in ISBN 10 and ISBN 13. See this Wikipedia article for details, but the two formulas are:
For ISBN 10 (the top one), the sum of all digits multiplied by mutlipliers 10-9-8-7-6-5-4-3-2-1 mod 11 should be 0:
0*10 + 7 *9 + 4*8 + 9*7 + 4*6 + 2*5 + 3*4 + 4*3 + 9*2 + 8*1 % 11 == 0
For ISBN 13 (the bottom one) the sum of the odd digits * 1 plus the sum of the even digits * 3 should be 0. This is including the leading 978. (this is similar to the UPC code as "user..." mentioned but a little different as noted in the Wikipedia article):
9*1 + 7*3 + 8*1 + 0*3 + 7*1 + 4*3 + 9*1 + 4*3 + 2*1 + 3*3 + 4*1 + 9*3 + 0*1 % 10 == 0
So you can get the ISBN 10 code (top) from the ISBN 13 (bottom) code as follows:
isbnBaseCode = <9780749423490 from the 4th to 12th characters>
isbn10CheckDigit = 11 - (isbnBaseCode[0]*10 + isbnBaseCode[1]*9 + ... + isbnBaseCode[8]*2) % 11
isbnCode10 = isbnBaseCode + isbn10CheckDigit
The long and short of your question is that they are in fact both ISBNs.
One is in the 10 digit format and the other is in the newer 13 digit format.
978 074942349 0
074942349 8
The 978 is a prefix and the last digit, on both, is a check digit .
The barcode on the item you are scanning only represents the 13 digit format.
According to http://www.isbn.org/standards/home/isbn/transition.asp
You can always convert from 13 digit ISBN starting with 978 to the 10 digit format
and provides a link to an online converter. It also discusses the 979 prefix.
I don't believe the 979 prefix is being used yet but its good to be aware that they may be used in future.
Having worked in the Library apps space, when searching a library catalog
item records will vary greatly in what information they contain.
Item records, specifically regarding ISBN, can contain the 10 digit ISBN, 13 digit ISBN, both, or none. So to find an item you might have to try both formats.
I believe that some systems, if your search type is set to ISBN, will actually check the submitted ISBN and search for both formats automatically.
Depending on what your trying to do.
Many library search functions allow for wild cards which may make it easier to find
the item your looking for. For example:
'if the isbn has a length of 13 and starts with 978
remove the first 3 (the 978) and last digit (the check digit)
add a wildcard character to the front and back
begin search
end if
eg 9780749423490 would become *07494234*
The downside is that it might return multiple results.
Even if that were to happen it would likely only be a couple items and the one your
looking, if there, would be easy to spot.
As provided by others the Wikipedia article on ISBN goes into more technical details on how to convert between the 10 and 13 digit formats.
http://en.wikipedia.org/wiki/International_Standard_Book_Number
The number starting 978 is a product code, specifically a UPC (Universal Product Code), that includes the ISBN but without the check digit at the end. Have a look at ISBN on wikipedia for code on generating the check digit and you'll be able to reconstruct the ISBN from the UPC.
I am reading brokenthorn.com ‘s O/S development tutorials one of the tutorials, the following code is there.
http://www.brokenthorn.com/Resources/OSDev3.html
I don’t understand why this code clear 510 bytes. org, bits, cli, hlt are there in the code too. Shouldn’t it be changed to less than 510 bytes? Could it be typo or something?
Thanks.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;*********************************************
; Boot1.asm
; - A Simple Bootloader
;
; Operating Systems Development Tutorial
;*********************************************
org 0x7c00 ; We are loaded by BIOS at 0x7C00
bits 16 ; We are still in 16 bit Real Mode
Start:
cli ; Clear all Interrupts
hlt ; halt the system
times 510 - ($-$$) db 0 ; We have to be 512 bytes. Clear the rest of the bytes with 0
dw 0xAA55 ; Boot Signiture
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
It's not clearing 510 bytes, it's clearing 510 - ($-$$) bytes. Since $ is the current position, and $$ is the start of the section, it's clearing 510 - (length of the section up to that point) bytes.
This will fill the block correctly up to two bytes from the 512 byte limit, and put the signature on the two last bytes.
The boot sector is 512 bytes long, and is identified as such by the final two bytes begin set to 0xAA55. This leaves 510 bytes for the loader's actual code, which is precisely what the provided example fills when assembled. If your resulting binary isn't precisely 512 bytes long then you may need to specify a plain binary output format, though in the case of nasm this is the default setting.
In practice there are other magic bytes which need to be present for partition tables and such, and typically the first stage loader is used for little more than reading in and executing some more code.