My operating system is Debian Squeeze. Here's the vim version:
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Jul 12 2010 02:29:33)
I read a tutorial on http://kovisoft.bitbucket.org/tutorial.html and tried to start REPL for MIT-Scheme. Unfortunately, I failed to start.
When I pressed ",c", it started a terminal window loading mit-scheme. Nothing showed in the REPL buffer of vim. Some errors showed in the terminal:
Listening on port: 4005
;netcat: "4005: inverse host lookup failed: Unknown host"
;To continue, call RESTART with an option number:
; (RESTART 1) => Return to read-eval-print level 1.
2 error>
I read the source code and fixed some bugs (about the parameters of netcat and something else), here's the diff file:
*** /home/gaussfrank/slimv/slime/contrib/swank-mit-scheme.scm 2012-02-02 16:41:58.357463955 +0800
--- swank-mit-scheme.scm 2012-02-06 22:30:42.929212874 +0800
***************
*** 113,126 ****
(define (netcat port)
(let* ((sh (os/shell-file-name))
! (cmd (format #f "exec netcat -v -q 0 -l ~a 2>&1" port))
(netcat (start-pipe-subprocess sh
(vector sh "-c" cmd)
scheme-subprocess-environment)))
(list netcat port)))
(define (netcat-accept nc)
! (let* ((rx "^Connection from .+ port .+ accepted$")
(line (read-line (subprocess-input-port nc)))
(match (re-string-match rx line)))
(cond ((not match) (error "netcat:" line))
--- 113,126 ----
(define (netcat port)
(let* ((sh (os/shell-file-name))
! (cmd (format #f "exec netcat -v -q 0 -l -p ~a 2>&1" port))
(netcat (start-pipe-subprocess sh
(vector sh "-c" cmd)
scheme-subprocess-environment)))
(list netcat port)))
(define (netcat-accept nc)
! (let* ((rx "^listening on.*")
(line (read-line (subprocess-input-port nc)))
(match (re-string-match rx line)))
(cond ((not match) (error "netcat:" line))
I retried, but some new problems happened.
;The object #f, passed as the second argument to integer-add, is not the correct type.
;To continue, call RESTART with an option number:
; (RESTART 4) => Specify an argument to use in its place.
; (RESTART 3) => Return to SLIME top-level.
; (RESTART 2) => Close connection.
; (RESTART 1) => Return to read-eval-print level 1.
Here's the log file (swank.log)
[---Sent---] 0.21
(:emacs-rex (swank:connection-info) nil t 1)
[---Sent---] 16.11
(:emacs-rex (swank:swank-require 'swank-fuzzy) nil t 2)
Here's the packet:
8 0.739991 127.0.0.1 127.0.0.1 TCP 50732 > pxc-pin [PSH, ACK] Seq=1 Ack=1 Win=32792 Len=51 TSV=1451459 TSER=1451459
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E.
0010 00 67 91 53 40 00 40 06 ab 3b 7f 00 00 01 7f 00 .g.S#.#..;......
0020 00 01 c6 2c 0f a5 f9 57 b4 93 fc 40 7f 85 80 18 ...,...W...#....
0030 10 03 fe 5b 00 00 01 01 08 0a 00 16 25 c3 00 16 ...[........%...
0040 25 c3 30 30 30 30 32 64 28 3a 65 6d 61 63 73 2d %.00002d(:emacs-
0050 72 65 78 20 28 73 77 61 6e 6b 3a 63 6f 6e 6e 65 rex (swank:conne
0060 63 74 69 6f 6e 2d 69 6e 66 6f 29 20 6e 69 6c 20 ction-info) nil
0070 74 20 31 29 0a t 1).
9 0.740009 127.0.0.1 127.0.0.1 TCP pxc-pin > 50732 [ACK] Seq=1 Ack=52 Win=32768 Len=0 TSV=1451459 TSER=1451459
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E.
0010 00 34 5a 46 40 00 40 06 e2 7b 7f 00 00 01 7f 00 .4ZF#.#..{......
0020 00 01 0f a5 c6 2c fc 40 7f 85 f9 57 b4 c6 80 10 .....,.#...W....
0030 10 00 fe 28 00 00 01 01 08 0a 00 16 25 c3 00 16 ...(........%...
0040 25 c3 %.
This is a known problem. I have a patched version of Slimv in my git repo which fixes this issue and quite a few others.
Note that it's quite a while ago that I used Slimv, so I can't recall from the top of my head what the exact changes are I made. I only tested this on OS X, so YMMV.
Related
I can't think of other way to run a command line that outputs binary files, so I'll have to go with this.
Let's add a binary file to a git repository
mkdir test
cd test
git init .
wget https://upload.wikimedia.org/wikipedia/commons/thumb/8/85/Camelia.svg/320px-Camelia.svg.png
git add 320px-Camelia.svg.png
git commit -am "Added Camelia"
Grab the commit hash that that outputs, we'll use it as <grabbed hash> below.
Now, run this:
say (run "git", "show", "<grabbed hash>:Camelia.svg.png", :out).out
This will return a Malformed UTF-8 message. Fair enough, it's not binary. However, I have tried to capture that exception with try and there's no way. I've tried to separate the run from the out, I still get an exception that can't be captured. Any idea?
Pass the :bin option to run in order to have it do binary I/O instead. Example using curl:
$ raku -e 'say (run "curl", "--no-progress-meter", "https://raku.org/camelia-logo.png", :out, :bin).out.slurp'
Buf[uint8]:0x<89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 01 05 00 00 00 F3 08 06 00 00 00 8F 2A 03 21 00 00 00 01 73 52 47 42 00 AE CE 1C E9 00 00 00 09 70 48 59 73 00 00 0F 61 00 00 0F 61 01 A8 3F A7 69 00 00 00 07 74 49 4D 45 07 D9 07 11 03 07 3A 28 6B FA 81 00 00 00 1A 74 45 58 74 43 6F 6D 6D 65 6E ...>
Does JCOP/J3A081 support int data type?
I am using latest eclipse JCOP tools for java card applet development. I need to store big integer values in a card so I have used the INTEGER data type (int) for balance in my applet. it is compiling without any error but getting error 6A80 on uploading the CAP file into JCOP J3A081 cards. I have tried all combinations of GP 2.1.1, GP 2.2.1, JDK 2.2.2, JDK 3.0.4 library but getting the same error.
Are int data type variables and JCint library supported by J3A/J2A series cards? if yes how to resolve the issue?
Applet source code:
Note: if I remove int data type variable and JCint references then no error comes.
- version
current version is 5.32.0.4 [1]
build timestamp is 27-01-2020 12:10:53
- /terminal
--Opening terminal
Session ID: 6527B91D44DD89CDE6AB60FCA590DF06
> /list-readers
----------------------
Name ( Type )
----------------------
> /card -v
Warning: Usage of /atr with no preceding of /reset is deprecated. /reset is invoked.
IOCTL().
ATR: 3B89800150565F4A334130383150
ATR:
Hist = PV_J3A081
T = 0
T = 1
=> 00 A4 04 00 00 .....
(12493 usec [SYS])
<= 6F 65 84 08 A0 00 00 00 03 00 00 00 A5 59 9F 65 oe...........Y.e
01 FF 9F 6E 06 47 91 00 78 34 00 73 4A 06 07 2A ...n.G..x4.sJ..*
86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B 03 64 ....c...*.H..k.d
0B 06 09 2A 86 48 86 FC 6B 04 02 15 65 0B 06 09 ...*.H..k...e...
2B 85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 +...Hd...f...+..
04 01 2A 02 6E 01 02 90 00 ..*.n....
Status: No Error
FCI Data:
Max. Block Length: 255
CPLC Data:
Operating System ID : 4791
Operating System release date : 0078 (18.3.20X0)
Operating System release level : 3400
Security Domain Management Data:
Global Platform Version: 2.1.1
Secure Channel Protocol: 02 (option 15)
cm> /identify
FABKEY ID: 0x02
PATCH ID: 0x21
TARGET ID: 0x00 (null)
MASK ID: 0x34 (52)
CUSTOM MASK: 00000000
MASK NAME: NX011D
FUSE STATE: fused
ROM INFO: 58E957
COMBO NAME: null-m34.02.21-NX011D
cm> get-cplc -v
=> 80 CA 9F 7F 00 .....
(8475 usec [SYS])
<= 9F 7F 2A 47 90 51 68 47 91 00 78 34 00 31 30 04 ..*G.QhG..x4.10.
81 33 96 75 18 48 12 31 37 00 00 00 00 0F 20 38 .3.u.H.17..... 8
34 38 31 33 33 00 00 00 00 00 00 00 00 90 00 48133..........
Status: No Error
IC Fabricator : 4790
IC Type : 5168
Operating System ID : 4791
Operating System release date : 0078 (18.3.20X0)
Operating System release level : 3400
IC Fabrication Date : 3130 (10.5.2003)
IC Serial Number : 04813396
IC Batch Identifier : 7518
IC Module Fabricator : 4812
IC Module Packaging Date : 3137 (17.5.2003)
ICC Manufacturer : 0000
IC Embedding Date : 0000
IC Pre-Personalizer : 0F20
IC Pre-Perso. Equipment Date : 3834
IC Pre-Perso. Equipment ID : 38313333
IC Personalizer : 0000
IC Personalization Date : 0000
IC Perso. Equipment ID : 00000000
cm> /cap-info "C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap"
CAP file name : C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap
CAP file version : 2.2
Java package name : com.pryogika.jc
Internal pkg. name : com/pryogika/jc
CAP file components :
Header.cap (38 Bytes)
Directory.cap (36 Bytes)
Import.cap (36 Bytes)
Applet.cap (22 Bytes)
Class.cap (17 Bytes)
Method.cap (82 Bytes)
StaticField.cap (13 Bytes)
ConstantPool.cap (41 Bytes)
RefLocation.cap (16 Bytes)
Descriptor.cap (90 Bytes)
Debug.cap (500 Bytes)
Integer support : yes
Package version : 1.0
Package AID : "HelloJCOP"
Import AIDs :
A0000000620101 (javacard.framework) version 1.3
A00000006202080101 version 1.0
A0000000620001 (java.lang) version 1.0
Applet AIDs :
"HelloJCOPApplet"
Code size to load : 301 bytes
Code size on card :
pkgAID : 9
applet AIDs : 22
classes : 17
methods : 82
statics : 0
exports : 0
-------------------------------------
overall : 130 bytes
SHA-256 (Load File data): FD9E6BDB25A9C863B83C1ECE829F66DBEAA64B38BF5CD4EA953651B110AAD209
SHA-256 (Load File dbg) : 07F25D2E0A470C0AFECCADEF1387986D70C71606E33DD339ED89F4CE1CA84467
SHA-256 (Load File) : CE72441BF5B56BB36A4AEBE3F3A96725D0A36926697B9187C3873C3437CBEAA4
SHA-1 (Load File data): C5EFC5FAAE4FB711E327F5563C48888EA56F81D5
SHA-1 (Load File dbg) : 41264E6C8F21F1C46F2BE7EBCF70CAE00624A277
SHA-1 (Load File) : EB826D7E56AFF5AAF4C4CD3FC4FB5850DD81D91F
DAP block(s) : none
Load Token(s) : none
Install Token(s) : none
Delete Token(s) : none
cm> set-key 1/1/DES-ECB/404142434445464748494a4b4c4d4e4f 1/2/DES-ECB/404142434445464748494a4b4c4d4e4f 1/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update
=> 80 50 00 00 08 11 A9 0F 67 2B 22 B6 E1 00 .P......g+"...
(37691 usec [SYS])
<= 00 00 31 30 04 81 33 96 75 18 01 02 00 3E 60 17 ..10..3.u....>`.
08 B3 12 20 F1 76 A5 F1 D0 6D 12 BD 90 00 ... .v...m....
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 3F BE FC 67 E2 96 5E DF A7 85 B1 .....?..g..^....
9C CF C3 A4 F2 .....
(42458 usec [SYS])
<= 90 00 ..
Status: No Error
cm> card-info
=> 80 F2 80 00 02 4F 00 00 .....O..
(8862 usec [SYS])
<= 08 A0 00 00 00 03 00 00 00 07 9E 90 00 .............
Status: No Error
=> 80 F2 40 00 02 4F 00 00 ..#..O..
(7220 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
=> 80 F2 10 00 02 4F 00 00 .....O..
(8838 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
Card Manager AID : A000000003000000
Card Manager state : INITIALIZED
cm> upload -b 250 "C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap"
=> 80 E6 02 00 16 09 48 65 6C 6C 6F 4A 43 4F 50 08 ......HelloJCOP.
A0 00 00 00 03 00 00 00 00 00 00 00 ............
(13758 usec [SYS])
<= 00 90 00 ...
Status: No Error
=> 80 E8 00 00 FA C4 82 01 2D 01 00 23 DE CA FF ED ........-..#....
02 02 05 00 01 09 48 65 6C 6C 6F 4A 43 4F 50 0F ......HelloJCOP.
63 6F 6D 2F 70 72 79 6F 67 69 6B 61 2F 6A 63 02 com/pryogika/jc.
00 21 00 23 00 21 00 13 00 21 00 26 00 0E 00 4F .!.#.!...!.&...O
00 0A 00 0D 00 00 00 57 00 00 00 00 00 00 00 00 .......W........
03 01 00 04 00 21 03 03 01 07 A0 00 00 00 62 01 .....!........b.
01 00 01 09 A0 00 00 00 62 02 08 01 01 00 01 07 ........b.......
A0 00 00 00 62 00 01 03 00 13 01 0F 48 65 6C 6C ....b.......Hell
6F 4A 43 4F 50 41 70 70 6C 65 74 00 08 06 00 0E oJCOPApplet.....
00 00 00 80 03 00 FF 00 07 01 00 00 00 1C 07 00 ................
4F 00 01 10 18 8C 00 00 7A 05 30 8F 00 01 3D 8C O.......z.0...=.
00 02 18 1D 04 41 18 1D 25 8B 00 03 7A 04 23 18 .....A..%...z.#.
8B 00 04 60 03 7A 19 8B 00 05 2D 1A 04 25 73 00 ...`.z....-..%s.
1B 00 00 00 00 00 09 12 0A 36 1A 08 23 8D 00 06 .........6..#...
3B 19 08 07 8B 00 07 70 08 11 6D 00 8D 00 08 7A ;......p..m....z
08 00 0A 00 00 00 00 00 00 00 00 00 00 05 00 00 ................
(25820 usec [SYS])
<= 6A 80 j.
Status: Wrong data
jcshell: Error code: 6a80 (Wrong data)
jcshell: Wrong response APDU: 6A80
cm> /list-v
Global:____________________________________________
SESSION.ID=0FA5DF09FC02F2276D5A113D1591EE7C
cap.applet.aids=48656C6C6F4A434F504170706C6574
cap.package.aid=48656C6C6F4A434F50
exec.dir=C:\Users\pp\Desktop
jcop.v242=false
last.apdu.executiontime=25.717
last.apdu.executiontime.unit=msec
last.executiontime=52.0
last.executiontime.unit=msec
last.response.status=6a80
logfile.list=
cm> card-info
=> 80 F2 80 00 02 4F 00 00 .....O..
(17196 usec [SYS])
<= 08 A0 00 00 00 03 00 00 00 07 9E 90 00 .............
Status: No Error
=> 80 F2 40 00 02 4F 00 00 ..#..O..
(20679 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
=> 80 F2 10 00 02 4F 00 00 .....O..
(8299 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
Card Manager AID : A000000003000000
Card Manager state : INITIALIZED
No, these cards have not supported the int type. For full certainty simply ask for the data sheet or user's manual from NXP, and if it is not in there, ask them directly.
If you want to support bigger data types then this is of course possible, but you'll have to program it yourself. In that case the fact that objects are stored in persistent memory will of course not be of any help, but it can be done.
Otherwise: it depends on what kind of integer support you require. Just addition or subtraction is very easy to implement yourself on a byte-by-byte base. For cryptographic purposes you may need to look a lot deeper. Sometimes you can also use existing API's such as DH key agreement to perform e.g. modular exponentiation. There are for instance libraries to perform Elliptic Curve calculations (which require big integer).
I use 'socat TCP4-LISTEN:8080,fork EXEC:./bashttpd' for http server. when try to receive image file from client socat remove some byte and corrupt my image.
correct:
01b0 0a 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 ..PNG........IHD
01c0 52 00 00 07 80 00 00 04 38 08 02 00 00 00 67 b1 R.......8.....g.
01d0 56 14 00 00 00 09 70 48 59 73 00 00 11 b0 00 00 V.
incorrect:(socat -> read line -> xxh)
00000000: 89 50 4e 47 0d 0a .PNG..
00000000: 1a 0a ..
00000000: 0d 49 48 44 52 07 80 04 38 08 02 67 b1 56 14 09 .IHDR...8..g.V
how to solve this problem?
thanks
Background is that I have a log file that contains hex dumps that I want to convert with xxd to get that nice ASCII column that shows possible strings in the binary data.
The log file format looks like this:
My interesting hex dump:
00 53 00 6f 00 6d 00 65 00 20 00 74 00 65 00 78
00 74 00 20 00 65 00 78 00 61 00 6d 00 70 00 6c
00 65 00 20 00 75 00 73 00 69 00 6e 00 67 00 20
00 55 00 54 00 46 00 2d 00 31 00 36 00 20 00 69
00 6e 00 20 00 6f 00 72 00 64 00 65 00 72 00 20
00 74 00 6f 00 20 00 67 00 65 00 74 00 20 00 30
00 78 00 30 00 30 00 20 00 62 00 79 00 74 00 65
00 73 00 2e
Visually selecting the hex dump and do xxd -r -p followed by a xxd -g1 on the result does exactly what I'm aiming for.
However, since the number of dumps I want to convert are quite a few I would rather automate the process.
So I'm using the following substitute command to do the conversion:
:%s/\(\x\{2\} \?\)\{16\}\_.*/\=system('xxd -g1',system('xxd -r -p',submatch(0)))
The expression matches the entire hex dump in the log file. The match is sent to xxd -r -p as stdin and its output is used as stdin for xxd -g1.
Well, that's the idea at least.
The thing is that the above almost works. It produces the following result:
My interesting hex dump:
00000000: 01 53 01 6f 01 6d 01 65 01 20 01 74 01 65 01 78 .S.o.m.e. .t.e.x
00000010: 01 74 01 20 01 65 01 78 01 61 01 6d 01 70 01 6c .t. .e.x.a.m.p.l
00000020: 01 65 01 20 01 75 01 73 01 69 01 6e 01 67 01 20 .e. .u.s.i.n.g.
00000030: 01 55 01 54 01 46 01 2d 01 31 01 36 01 20 01 69 .U.T.F.-.1.6. .i
00000040: 01 6e 01 20 01 6f 01 72 01 64 01 65 01 72 01 20 .n. .o.r.d.e.r.
00000050: 01 74 01 6f 01 20 01 67 01 65 01 74 01 20 01 30 .t.o. .g.e.t. .0
00000060: 01 78 01 30 01 30 01 20 01 62 01 79 01 74 01 65 .x.0.0. .b.y.t.e
00000070: 01 73 01 2e .s..
All 00 bytes have mysteriously transformed into 01.
It should have produced the following:
My interesting hex dump:
00000000: 00 53 00 6f 00 6d 00 65 00 20 00 74 00 65 00 78 .S.o.m.e. .t.e.x
00000010: 00 74 00 20 00 65 00 78 00 61 00 6d 00 70 00 6c .t. .e.x.a.m.p.l
00000020: 00 65 00 20 00 75 00 73 00 69 00 6e 00 67 00 20 .e. .u.s.i.n.g.
00000030: 00 55 00 54 00 46 00 2d 00 31 00 36 00 20 00 69 .U.T.F.-.1.6. .i
00000040: 00 6e 00 20 00 6f 00 72 00 64 00 65 00 72 00 20 .n. .o.r.d.e.r.
00000050: 00 74 00 6f 00 20 00 67 00 65 00 74 00 20 00 30 .t.o. .g.e.t. .0
00000060: 00 78 00 30 00 30 00 20 00 62 00 79 00 74 00 65 .x.0.0. .b.y.t.e
00000070: 00 73 00 2e .s..
What am I not getting here?
Of course I can use macros and other ways of doing this, but I want to understand why my substitution command doesn't do what I expect.
Edit:
For anyone that want to achieve the same thing I provide the substitution expression that works on an entire file. The expression above was only for testing purposes using the log file example also from above.
The one below is the one that performs a correct conversion, modified based on the information Kent provided in his answer.
:%s/\(\(\x\{2\} \)\{16\}\_.\)\+/\=system('xxd -p -r | xxd -g1',submatch(0))
very likely, the problem is string conversion in the system() The input will be converted into a string by vim, so does the output of your first xxd command.
You can try to extract that hex parts into a file. then:
xxd -r -p theFile|vim -
And then calling the system('xxd -g1', alltext), you are gonna get something else than 00 too.
This doesn't work in the same way of a pipe (xxd ...|xxd...). But unfortunately, the system() function doesn't accept pipes.
If you want to fix your :s command, you need to call systemlist() on your first xxd call to get the data in binary format, then pass it to the 2nd xxd:
:%s/\(\x\{2\} \?\)\{16\}\_.*/\=system('xxd -g1',systemlist('xxd -r -p',submatch(0)))
The cmd above will generate the 00s. since there is no string conversion.
However, when working with some data format other than plain string, perhaps we can use filters instead of calling system(). It would be a lot eaiser. For your example:
2,$!xxd -r -p|xxd -g1
I am unable to unzip file in linux centos. Getting following error
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
As you are mentioning jar in your comments we can consider this a programming question ;-)
First of all you should try to validate your file. If available you can even compare the checksum provided for this file and / or the filesize with the location you downloaded it from.
To verify the zip file on a low level you can use this command:
hexdump -C -n 100 file.zip
This will show you the first 100 bytes of the zips structure which will look similar to this:
00000000 50 4b 03 04 0a 00 00 00 00 00 88 43 65 47 11 7a |PK.........CeG.z|
00000010 39 1e 15 00 00 00 15 00 00 00 0e 00 1c 00 66 69 |9.............fi|
00000020 6c 65 31 69 6e 7a 69 70 2e 74 78 74 55 54 09 00 |le1inzip.txtUT..|
00000030 03 0f 05 3b 56 2f 05 3b 56 75 78 0b 00 01 04 e8 |...;V/.;Vux.....|
00000040 03 00 00 04 e8 03 00 00 54 68 69 73 20 69 73 20 |........This is |
00000050 61 20 66 69 6c 65 0a 1b 5b 31 37 7e 0a 50 4b 03 |a file..[17~.PK.|
00000060 04 0a 00 00 |....|
The first two byte of the file have to be PK, if not the file is invalid. Some bytes later you will find the name of the first file stored. In this example it is file1inzip.txt.