David Haller wrote:
current_line = $0; if( ! seen_this_line[current_line] ) { seen_this_line[current_line] = 1; print current_line; }
No need to sort anything ;)
Think of this history:
.... I think we have a different idea of history. When I took history, it wasn't about cataloging a random sequence of events, but having some idea of when they occurred. I.e. If I know I've used a certain command for years, then figured out an improvement 3 weeks ago, I want to look for the commands from 3 weeks ago, on to see the corrected version. The behavior your script shows may be what *you* want: a grab-bag of previously used commands in a random order, but for my usage, I NEED commands grouped and sorted by when they occurred. I will often build up scripts through successive edits and then alternate specific parameters. If my history isn't sorted, I won't see the context of the command (CWD, variable values, defined functions and aliases). Without those, the usefulness of recalling a command with none of its "setup" or "environment" command is negligible. As an example -- wanted to install a package. If I search on the package I might find: spm -Uhv /factory/computertemp-0.9.6.1-24.1.x86_64.rpm But that won't help since *after* that command * see successive building up of requirements in the history. After 7 retries, I I ended up with: spm --replacepkgs -Uhv /factory/computertemp-0.9.6.1-24.1.x86_64.rpm /factory/gnome-python-desktop-2.32.0-19.1.x86_64.rpm python-gnomedesktop-2.32.0-19.1.x86_64.rpm python-gnomeprint-2.32.0-19.1.x86_64.rpm python-gtop-2.32.0-19.1.x86_64.rpm python-rsvg-2.32.0-19.1.x86_64.rpm python-totem-2.32.0-19.1.x86_64.rpm python-wnck-2.32.0-19.1.x86_64.rpm libgnome-desktop-3-7-3.8.2-1.1.x86_64.rpm libgnome-desktop-2-17-2.32.1-20.1.x86_64.rpm libgnomeprintui-2.18.6-14.1.x86_64.rpm If I am searching backwards -- because the lines are sorted w/date & time, The final version is the 1 that will come up first.
I.e. if you run unsorted input into 'uniq', you won't get 'uniq' output. Also not sure why the time command is there? Are you trying to time the tac command?
No, the whole thing, just out of curiosity. On my ~225k lines it took about 4.5s.
ah.
I ran your script on a concatenation of my 'tty-hist files' and first few lines of output from your script were: [..] #1328153686 ls repo-oss #1328153702 ls repo-oss/suse/x86_64/ #1328153720 rpm -qpi repo-oss/suse/x86_64/xfce4-panel-plugin-xkb-0.5.3.3-7.1.x86_64.rpm
Oh, you use timestamps. It won't work then. If you grab a test file and filter out the timestamps, e.g.:
---- A history file in a random order isn't a history file. It's a grab-bag.
grep '^#' historyfile > tmp.hist
and run my script on that tmp.hist, you'll see it works ;)
--- I'd lose potentially all context.
1) why would your script keep 'uniq' blank lines? I.e. the consecutive timestamps w/no command & 2, the output from your script shows its 1st command starting
They're not blank.
head -13 cat.hist #1382638179
---- Except for the 1st , the rest are blank lines -- a timestamp, no content followed by a 'LF': ps -ef|grep fetch #1382791092 #1382791960 #1382792415 #1382793525 #1382815570 #1382816176 #1382815576 #1382816222 #1382870743 #1382870876 #1382815581
From the 2nd timestamp through the last, they are blank (only an "\n" on the timestamp line):
head -13 cat.hist|hexdump -C 00000000 23 31 33 38 32 36 33 38 31 37 39 0a 70 73 20 20 |#1382638179.ps | 00000010 2d 65 66 7c 67 72 65 70 20 66 65 74 63 68 0a 23 |-ef|grep fetch.#| 00000020 31 33 38 32 37 39 31 30 39 32 0a 23 31 33 38 32 |1382791092.#1382| 00000030 37 39 31 39 36 30 0a 23 31 33 38 32 37 39 32 34 |791960.#13827924| 00000040 31 35 0a 23 31 33 38 32 37 39 33 35 32 35 0a 23 |15.#1382793525.#| 00000050 31 33 38 32 38 31 35 35 37 30 0a 23 31 33 38 32 |1382815570.#1382| 00000060 38 31 36 31 37 36 0a 23 31 33 38 32 38 31 35 35 |816176.#13828155| 00000070 37 36 0a 23 31 33 38 32 38 31 36 32 32 32 0a 23 |76.#1382816222.#| 00000080 31 33 38 32 38 37 30 37 34 33 0a 23 31 33 38 32 |1382870743.#1382| 00000090 38 37 30 38 37 36 0a 23 31 33 38 32 38 31 35 35 |870876.#13828155| 000000a0 38 31 0a |81.|
From the 2nd timestamp through the last, they are blank.
You should crosscheck results with your script etc. Any questions?
---- I _know_ it won't produce the results that _I_ want for history: I want a 'history', not a list of events w/no context. What is history with no reference to when or in what context it occurred? FWIW -- I may have 10 concurrent history files building up via 10 pty-windows. Sorting and merging I can see results of inter-related commands in separate windows. Sorting using 'tac' wouldn't work for retrieving the most recent usage. Example -- in my .hist$HOSTNAME_pts dir I have 'N' separate files: pty's: ~/.histIshtar_pts> ll -rt [0-9] 1[0-9] -rw-rw-r--+ 1 890 Jan 1 2014 17 -rw-rw-r--+ 1 3007 Aug 24 2014 16 ... -rw-rw-r--+ 1 2652854 Apr 4 17:24 1 -rw-rw-r--+ 1 640283 Apr 5 06:59 3 -rw-rw-r--+ 1 999883 Apr 5 07:02 0 As you run your merge on each pty you'll end up with one big file that has 'N' "ranges" of history containing, overlapping time-ranges -- with commands in different tty sessions: File 1, above ranges from:
head -1 1|grep -P '#\d+$' #1328153686 ~/.histIshtar_pts> unix_epoch2date 1328153686 Wed Feb 1 19:34:46 PST 2012 <<--start
~/.histIshtar_pts> tail -2 1|grep -P '#\d+$' #1428143038 ~/.histIshtar_pts> unix_epoch2date 1428143038 Sat Apr 4 03:23:58 PDT 2015 <<--end --- File 3 (defining a func)
sub drange { echo "Start: $(unix_epoch2date $(head -1 $1|grep -P '#\d+$'|tr -d '#'))" echo "End: $(unix_epoch2date $(tail -2 $1|grep -P '#\d+$'|tr -d '#'))" } drange 3 Start: Thu Oct 24 03:59:17 PDT 2013 End: Sat Apr 4 18:59:17 PDT 2015 ... etc.
If you drop out the timestamp, then once you've concatenated the results you'll have a mish-mash of recent->early commands and if you return the most recent and don't have a it sorted, you won't really get the most recent usage of that command. However, if all you want is a semi-random-grab-bag of previous commands, you don't need the timestamp -- but is it really a "HISTORY" file then? But if it works for your purposes... that's all that's needed! ;-) (And BTW, I, really, have done little testing on the correctness of my script, but it seemed to do about 90% of what I wanted, so I didn't spend more time on it...) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org