Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I have a log file in a custom binary format sitting on a remote machine. I want to sync it with a file on my local machine, so when new bytes are appended to the remote binary file, the file on my local machine will be updated as well.
I learned about how to use tail over ssh here: https://serverfault.com/questions/608723/tail-a-file-from-ssh-and-mirror-to-a-local-file
Then I learned about how to use tail on binary files here: Binary "tail" a file
I tried combining them into
ssh -t remotebox "tail -c +1 -f /path/to/file.bin" > ./mirror.bin
But then I realized that mirror.bin is corrupted. Looking at the hex dump, I see that all 0d0a bytes are truncated into 0as (\r\n got replaced by just \n). However, if I run tail locally (tail -c +1 -f file1.bin > file2.bin), this truncation does not happen.
I also tried to use tee instead of redirection; the problem persists.
Are there shell tricks I can do with tail to prevent this from happening, or are there other programs that suites my needs?
Thanks.
P.S. Both remote and local machines are Linux, running bash.
The following reproduces the problem:
$ echo -e '123\r\n234\r\n' > /tmp/1
$ scp /tmp/1 server:/tmp/1
$ ssh -t server cat /tmp/1 > /tmp/2
Shared connection to closed.
$ diff /tmp/1 /tmp/2
1,3c1,3
< 123
< 234
<
---
> 123
> 234
>
It's possible that ssh -t changes \r\n to \n because it might do stty +igncr on the line. Mine ssh -t does the opposite (I think stty +inlcr) and I have the character doubled:
$ ssh -t server cat /tmp/1 | hexdump -C
Shared connection to closed.
00000000 31 32 33 0d 0d 0a 32 33 34 0d 0d 0a 0d 0a |123...234.....|
0000000e
$ ssh server cat /tmp/1 | hexdump -C
00000000 31 32 33 0d 0a 32 33 34 0d 0a 0a |123..234...|
0000000b
Anyway. remove the -t option if you do not have the intention to use terminal features.
And your command line suggest that you are copying a file. I have no idea why do you use tail for that - tail it's for outputting last part of file, not for printing the whole file... To print the whole file use cat. To copy a file, use scp.
Related
First I find the process' pid with ps:
% ps -a | grep 'a.out'
output:
36296 pts/0 00:00:07 a.out
Then I get an image of this process with gcore:
% sudo gcore 36296
output:
0x0000558eab27d131 in main ()
warning: Memory read failed for corefile section, 4096 bytes at 0xffffffffff600000.
Saved corefile core.36296
[Inferior 1 (process 36296) detached]
Then, hex dump object:
% hd core.36296 | grep 'HOME'
output:
001f4a90 3d 32 00 48 4f 4d 45 3d 2f 68 6f 6d 65 2f 63 61 |=2.HOME=/home/ca|
Now, I'm trying to find the section where environment variables is loaded. How can I do this ?
You should use a debugger!
For linux, gcc and gdb you can do:
> gdb <executable> <core-file>
Within gdb you now can examine the environment from the core file:
(gdb) print ((char**)__environ)[0]
$1 = 0x7ffc6aba0a58 "SHELL=/bin/bash"
(gdb) print ((char**)__environ)[1]
$2 = 0x7ffc6aba0a68 "SESSION_MANAGER=local/unix:#/tmp/.ICE-unix/1873,unix/unix:/tmp/.ICE-unix/1873"
unless you get a string with length 0.
If you do not have an executable with debug infos, you also can try to find the text with:
strings –a <core-file>
But before you write a core file and try to search in it, you simply can get the environment from a process by using ps if your program is still running:
ps eww <pid>
I need to send a PEM-formatted certificate for storaging on a module that can be communicated with through the AT command set via a serial interface on one of Linux device nodes in /dev.
So far I've been using mostly
echo 'AT' > /dev/ttyX
to issue the necessary commands and it has done the trick just fine.
Any output from the device is monitored with cat /dev/ttyX on another terminal window.
I now have a certificate file encoded with ANSI. The documentation tells me to input it to the module using only LF line breaks and to terminate the input with Ctrl+Z, which I believe is hex 0x1A. The document also specifies that the certificate file may not end with an EOF character. I have used a hex editor to verify that the file is formatted as it should be.
I've tried to use both echo and printf to send the certificate chars / string to the module.
I have tried to include the 0x1A character in both the file and send it separately after the certificate chars like so:
printf '\x1a' > /dev/ttyX
or alternatively
echo -n -e '\x1a' > /dev/ttyX
The module seems to acknowledge the 0x1A as it stops the >-prompt for certificate and gives me the most verbose reply ever: ERROR
Generally, I'm sending the certificate file contents as follows:
echo -e "$(cat certfile)" > /dev/ttyX
or
printf '%b' "$(cat certfile)" > /dev/ttyX
Please assume that I have access to basic Linux shell tools (such as echo, printf, nano, stty and so on) with no option to trivially install new ones. I use SSH to access the target device and pscp to transfer the file to the target device. I also have a Windows rig on the side.
Any suggestions what else I should take into consideration? Maybe an stty option that I've missed? Does cat do something nasty in the input phase? A revealing trick to investigate the actual character data about to be send to the module? Some weird kink with serial comms I've missed?
If I
printf '%b' "$(cat cert)" > ./testoutput
and
od -x testoutput
the file looks alright in hex (I reordered the output from od -x manually, it seems to make pairs of the hex digits and switch them around). For example the end is:
2d 2d 2d 2d 2d 45 4e 44 20 43 45 52 54 49 46 49 43 41 54 45 2d 2d 2d 2d 2d 0a 1a 00
There must be something in stty or the receiving end that's causing trouble. Right?
For example the end is:
2d 2d 2d 2d 2d 45 4e 44 20 43 45 52 54 49 46 49 43 41 54 45 2d 2d 2d 2d 2d 0a 00 1a
Wait a sec. What's that 00 doing there, right before the 1a?
That doesn't belong. Try removing it.
I am trying to find a call function in a binary file, so I tried this:
Compile my code (in C),
Use the command: mips-mti-linux-gnu-objdump -d myapp.elf> objdump.txt
My function in objdump.txt file: 9d003350: 42000828 myfunction 0x1
Now, I want to identify this function in myapp.bin when reading this from memory. But, I get this: 28080042.
I tried to use the command: xxd -ps myapp.bin> xxd.txt
Just can find: 28080042.
Is it possible to do that?
That's an endianness conflict. objdump and xxd are giving you the same bytes, they're just using different endianness.
Actual bytes in order:
28 08 00 42
Big endian value:
28 08 00 42
Little endian value:
42 00 08 28
xxd -p will print out the individual bytes in the file in the order in which they exist.
objdump is disassembling it, it knows that the bytes belong in groups of 4, and it's interpreting them as little-endian.
xxd can print in little-endian order, using the -e flag (with a default grouping of 4 bytes, use the -g flag to change the number of bytes per group). However, this is incompatible with the -p flag, because the -p flag ignores any grouping.
objdump can be made to print in big-endian order, using the -EB flag, however, this will affect what instructions it reports.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am under mac os X and I want to find some words in the documentation of Homebrew.
This is a part of the documentation (man brew):
I tried this command
man brew | grep -e 'another installed' --color -B 2
and it worked well, below the result:
o leaves: Show installed formulae that are not dependencies of
another installed formula.
This command
man brew | grep -e 'leaves' --color -B 2
instead did not produce any output.
So I tried to use
brew | grep -e 'leaves.*' --color -B 2
but it did not work too.
I want to use grep to find the word 'leaves' inside the documentation of Homebrew and print the nearest lines to be able to understand what this option mean.
I know that maybe it is a stupid error but I am not able to figure out where it is.
Can someone help me?
The problem is not with grep so much as with man. When you view a manual page, formatting codes are interspersed in order to make the text appear bold (or underlined, etc).
bash-3.2#yosemite$ man brew | grep l..e..a..v..e..s
o leaves: Show installed formulae that are not dependencies of
bash-3.2#yosemite$ man brew | grep l..e..a..v..e..s | xxd
0000000: 2020 2020 2020 202b 086f 2020 206c 086c +.o l.l
0000010: 6508 6561 0861 7608 7665 0865 7308 733a e.ea.av.ve.es.s:
0000020: 2053 686f 7720 2069 6e73 7461 6c6c 6564 Show installed
0000030: 2020 666f 726d 756c 6165 2020 7468 6174 formulae that
0000040: 2020 6172 6520 206e 6f74 2020 6465 7065 are not depe
0000050: 6e64 656e 6369 6573 2020 6f66 0a ndencies of.
The traditional workaround is to filter formatted output through colcrt:
bash-3.2#yosemite$ man brew | colcrt | grep leaves
+ leaves: Show installed formulae that are not dependencies of
... but the resulting text is kind of crudely forced to ASCII only. A better solution for most people is to use LESS as your manual pager.
bash-3.2#yosemite$ export PAGER=less
bash-3.2#yosemite$ man brew
# ... type /leaves at the `less` prompt
o leaves: Show installed formulae that are not dependencies of
another installed formula.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I have a compressed file size of about 9.5 GB and want to transfer from one server to another server, I tried to use like the below,
server2:
nc -lp 1234 > file.tar.gz
server1:
nc -w 1 1234 < file.tar.gz
its not working.
I tried so many ways.
One machine is CentOS 6.4 and the other one is Ubuntu 12.04 LTS
Thanks in advance.
On receiving end:
nc -l 1234 > file.tar.gz
On sending end:
cat file.tar.gz | nc <reciever's ip or hostname> 1234
That should work. Depending on the speed, it may take a while but both processes will finish when the transfer is done.
From the nc(1) man page:
-l Used to specify that nc should listen for an incoming connection rather than initiate
a connection to a remote host. It is an error to use this option in conjunction with
the -p, -s, or -z options.
So your use of -p is wrong.
Use on server2:
nc -l 1234 > file.tar.gz
And on server1:
nc server2 1234 < file.tar.gz
from the sender
nc -v -w 30 1337 - l < filename
where "-v" from verbose, "-w 30" for a wait before and after 30 sec for the connection, "1337" port number, "-l" tell nc that this is a sender
from the receiver
nc -v -w 2 ip_add_of_sender 1337 > filename