I am expecting the output of following command as 03 not 3:
$expr 01 + 02
3
Do have any alternate way to get o/p like 01, 02...09
(Running command on Solaris8)
Related
I need help in the conceptual area surrounding:
/usr/bin/screen,
~/.screenrc,
termcap
My Goal: is to create a 'correctly' formatted log file via 'screen'.
Symptom: The log file contains hundreds of carriage-return bytes [i.e. (\015) or (\r) ]. I would like to replace every carriage-return byte with a linefeed byte [i.e. (\012) or (\n)].
My Approach: I have created the file: ~/.screenrc and added a 'termcap' line to it with the hope of intercepting the inbound bytes and translating the carriage-return bytes into linefeed bytes BEFORE they are written to the log file. I cycled through nine different syntactical forms of my request. None had the desired effect (see below for all nine forms).
My Questions:
Can my goal be accomplished with my approach?
If yes, what changes do I need to make to achieve my goal?
If no, what alternative should I implement?
Do I need to mix in the 'stty' command?
If yes, how?
Note: I can create a 'correctly' formatted file using the log file as input to 'tr':
$ /usr/bin/tr '\015' '\012' <screenlog.0 | head
<5 BAUD ADDRESS: FF>
<WAITING FOR 5 BAUD INIT>
<5 BAUD ADDRESS: 33>
<5 BAUD INIT: OK>
Rx: C233F1 01 00 # 254742 ms
Tx: 86F110 41 00 BE 1B 30 13 # 254753 ms
Tx: 86F118 41 00 88 18 00 10 # 254792 ms
Tx: 86F128 41 00 80 08 00 10 # 254831 ms
Rx: C133F0 3E # 255897 ms
Tx: 81F010 7E # 255903 ms
$
The 'screen' log file ( ~/screenlog.0 ) is created using the following command:
$ screen -L /dev/tty.usbserial-000014FA 115200
where:
$ ls -dl /dev/*usb*
crw-rw-rw- 1 root wheel 17, 25 Jul 21 19:50 /dev/cu.usbserial-000014FA
crw-rw-rw- 1 root wheel 17, 24 Jul 21 19:50 /dev/tty.usbserial-000014FA
$
$
$ ls -dl ~/.screenrc
-rw-r--r-- 1 scottsmith staff 684 Jul 22 12:28 /Users/scottsmith/.screenrc
$ cat ~/.screenrc
#termcap xterm* 'XC=B%,\015\012' # 01 no effect
#termcap xterm* 'XC=B%\E(B,\015\012' # 02 no effect
#termcap xterm* 'XC=B\E(%\E(B,\015\012' # 03 no effect
#terminfo xterm* 'XC=B%,\015\012' # 04 no effect
#terminfo xterm* 'XC=B%\E(B,\015\012' # 05 no effect
#terminfo xterm* 'XC=B\E(%\E(B,\015\012' # 06 no effect
#termcapinfo xterm* 'XC=B%,\015\012' # 07 no effect
#termcapinfo xterm* 'XC=B%\E(B,\015\012' # 08 no effect
termcapinfo xterm* 'XC=B\E(%\E(B,\015\012' # 09 no effect
$
$ echo $TERM
xterm-256color
$ echo $SCREENRC
$ ls -dl /usr/lib/terminfo/?/*
ls: /usr/lib/terminfo/?/*: No such file or directory
$ ls -dl /usr/lib/terminfo/*
ls: /usr/lib/terminfo/*: No such file or directory
$ ls -dl /etc/termcap
ls: /etc/termcap: No such file or directory
$ ls -dl /usr/local/etc/screenrc
ls: /usr/local/etc/screenrc: No such file or directory
$
System:
MacBook Pro (17-inch, Mid 2010)
Processor 2.53 GHz Intel Core i5
Memory 8 GB 1067 MHz DDR3
Graphics NVIDIA GeForce GT 330M 512 MB
OS X Yosemite Version 10.10.4
Screen(1) Mac OS X Manual Page: ( possible relevant content ):
CHARACTER TRANSLATION
Screen has a powerful mechanism to translate characters to arbitrary strings depending on the current font and terminal type. Use this feature if you want to work with a common standard character set (say ISO8851-latin1) even on terminals that scatter the more unusual characters over several national language font pages.
Syntax: XC=<charset-mapping>{,,<charset-mapping>}
<charset-mapping> := <designator><template>{,<mapping>}
<mapping> := <char-to-be-mapped><template-arg>
The things in braces may be repeated any number of times.
A tells screen how to map characters in font ('B': Ascii, 'A': UK, 'K': german, etc.) to strings. Every describes to what string a single character will be translated. A template mechanism is used, as most of the time the codes have a lot in common (for example strings to switch to and from another charset). Each occurrence of '%' in gets substituted with the specified together with the character. If your strings are not similar at all, then use '%' as a template and place the full string in . A quoting mechanism was added to make it possible to use a real '%'. The '\' character quotes the special char- acters '\', '%', and ','.
Here is an example:
termcap hp700 'XC=B\E(K%\E(B,\304[,\326\\,\334]'
This tells screen how to translate ISOlatin1 (charset 'B') upper case umlaut characters on a hp700 terminal that has a german charset. '\304' gets translated to '\E(K[\E(B' and so on. Note that this line gets parsed three times before the internal lookup table is built, therefore a lot of quoting is needed to create a single '\'.
Another extension was added to allow more emulation: If a mapping translates the unquoted '%' char, it will be sent to the terminal whenever screen switches to the corresponding . In this special case the template is assumed to be just '%' because the charset switch sequence and the char- acter mappings normally haven't much in common.
This example shows one use of the extension:
termcap xterm 'XC=K%,%\E(B,[\304,\\\326,]\334'
Here, a part of the german ('K') charset is emulated on an xterm. If screen has to change to the 'K' charset, '\E(B' will be sent to the terminal, i.e. the ASCII charset is used instead. The template is just '%', so the mapping is straightforward: '[' to '\304', '\' to '\326', and ']' to '\334'.
The section on character translation is describing a feature which is unrelated to logging. It is telling screen how to use ISO-2022 control sequences to print special characters on the terminal. In the manual page's example
termcap xterm 'XC=K%,%\E(B,[\304,\\\\\326,]\334'
this tells screen to send escape(B (to pretend it is switching the terminal to character-set "K") when it has to print any of [, \ or ]. Offhand (referring to XTerm Control Sequences) the reasoning in the example seems obscure:
xterm handles character set "K" (German)
character set "B" is US-ASCII
assuming that character set "B" is actually rendered as ISO-8859-1, those three characters are Ä, Ö and Ü (which is a plausible use of German, to print some common umlauts).
Rather than being handled by this feature, screen's logging is expected to record the original characters sent to the terminal — before translation.
I have a CSV with lots of lines delimited by comma. I have to convert it to text.
66012523,39,Feb 02 2015 05:19AM,
66012523,39,Feb 02 2015 09:53AM,
66012523,39,Feb 02 2015 01:38PM,
I used command cp source.csv destination.csv and also cat source.csv > destination.txt but it does output in the same format witch each line coming in new one. It just gets appended together. It outputs like
66012523,39,Feb 02 2015 05:19AM,66012523,39,Feb 02 2015 09:53AM,66012523,39,Feb 02 2015 01:38PM
How do I make them to output each line in newline. Please help.
I hypothesise that the first block in your question is what you WANT, and what you actually HAVE is
66012523,39,Feb 02 2015 05:19AM,66012523,39,Feb 02 2015 09:53AM,66012523,39,Feb 02 2015 01:38PM
So what you want to do, I hypothesise, is split this up into separate lines.
Am I right?
This is a bit rough-and-ready but it works. Relies on each group ending "M," and there being no other "M,"s in the text - which there aren't but I wouldn't call it robust.
sed s/M,/'\n'/g source.csv
Hi I am trying to Save my egrep results into a variable and do a foreach.
However, i keep getting the following error despite with the following type of codes
#!/bin/sh
RESULT1=$(egrep 'Begin|End' $SYNCLOG)
RESULT2=egrep 'Begin|End' $SYNCLOG
RESULT3="egrep 'Begin|End' $SYNCLOG"
Errror
./test.sh: syntax error at line 24: `RESULT=$' unexpected
I am trying to get my egrep results to be saved into the variable.
The egrep will return the following results
File 2:Begin - Date :Fri Jan 10 22:44:47 SGT 2014
File 2:End - Date :Fri Jan 10 22:47:06 SGT 2014
File 3:Begin - Date : Tue Jan 11 22:32:54 SGT 2014
File 3:End - Date : Tue Jan 11 22:34:43 SGT 2014
File 4:Begin - Date : Wed Jan 12 22:46:15 SGT 2014
File 4:End - Date : Wed Jan 12 22:48:23 SGT 2014
File 5:Begin - Date : Thu Jan 13 22:30:31 SGT 2014
File 5:End - Date : Thu Jan 13 22:32:51 SGT 2014
Problem is this shebang of sh:
#!/bin/sh
And use of $(...), which is a BASH syntax.
To fix, you can use this shebang to use bash instead:
#!/bin/bash
Or else use this command substitution syntax in /bin/sh:
RESULT1=`egrep 'Begin|End' $SYNCLOG`
it seems you have backticks somewhere on line 24. Paste your whole script. Above shell script excerpt i.e.
RESULT1=$(egrep 'Begin|End' $SYNCLOG)
Should work.
I've coded the following script in shell that creates a folder in a directory, then moves all images to this directory and then converts it and puts to a folder before. if I do this process manually it works fine, but apparently there's a conflict between the "convert" command and my loop. the "big" folder is the one that will retain the images with its original sizes and then the "tabloid" folder will contain thumbnail-sized formats of the same images.
cd tabloid
mkdir big
mv * big
cd big
for i in 00 01 02 03 04 05 06 07 08 09 10 11
do
convert -resize 351×383 "$i.jpg" "../$i.jpg"
done
it returns the following error:
convert.im6: invalid argument for option `-resize': 351×383 # error/convert.c/ConvertImageCommand/2382.
I don't know what could be wrong with my script. apparently it's in the loop because if I do the process manually (converting image per image via terminal), it works fine.
That's not an ASCII x (0x78) in your convert line that's × (MULTIPLICATION SIGN 0xd7).
I've got a large log file and I need to confirm the chronological timestamped entries sequence. I know how to read line 1 and extract the timestamp. I then need to compare it to lines 2 > line last. If there's any that are earlier than line 1 then print the whole line and continue until line last. Then read line 2 and repeat above for lines 3 > line last. Then read line 3 and repeat above for lines 4 > line last. The outside loop reading from the log file is no problem but how do I read the same file again starting at the line n+1 compared to the line number the outside loop is reading please? I.e. If the outside loop has read line 10, how do I get the inside loop to read the file starting at line 11? The log file has 10,000's line and I have several dozen log files to process, so speed is important.
Log file line format is:
Sep 17 16:09:51 2014 blah blah blah…
Sep 17 16:09:52 2014 blah blah blah…
Sep 17 16:09:52 2014 blah blah blah…
Sep 17 15:11:10 2014 blah blah blah…
Sep 17 16:11:10 2014 blah blah blah…
I'm trying to detect entries like line 4.
I can switch to Perl if it's faster.
Should I read the log file into an array to make the internal loop relative read position easy to do, or will the file size make the array size prohibitive?