Timeline for extract from line to line and then save to separate file
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 5, 2015 at 17:54 | comment | added | mikeserv | @don_crissti - i >= j = 1-line i address; j > i = regular 2-line i,j address; j > $ && i <= $ = 2-line i,$ address; i > $ && j > $ = 2-line no-match address; i < 1 || j < 1 = syntax error (excepting GNU's 0,... address form). Thinking about it, though, I'm not certain if j > $ is definitely equivalent to i,$. One way I can imagine that they might differ is w/ c. Try i,$ctext and i,$+1ctext - i think it might behave differently. Or maybe not. | |
| Jul 5, 2015 at 3:19 | comment | added | mikeserv | @don_crissti - I think it should have. some old seds - Solaris - will refuse to count that high, though. The line numbers must go that high as well. And you need write permissions. And the required space. All of that's just the obvious. It looks good to me - maybe OP just didn't like to wait for it. So I dunno. I never know with this place. | |
| Jul 5, 2015 at 2:59 | comment | added | don_crissti | Mike, this is totally unrelated to your answer here but I'm just curious... if you read the question again, why wouldn't OP's "last try" work ? Are there sed's out there that don't support w ? The accepted answer does pretty much the same only with p and >... Makes no sense... | |
| Apr 7, 2015 at 2:24 | history | edited | mikeserv | CC BY-SA 3.0 | added 1154 characters in body |
| Apr 7, 2015 at 2:18 | history | edited | mikeserv | CC BY-SA 3.0 | added 1154 characters in body |
| Mar 17, 2015 at 21:59 | comment | added | mikeserv | @don_crissti - not at all. | |
| Mar 17, 2015 at 21:45 | comment | added | mikeserv | @don_crissti - Yeah - it's doing lseek(): [pid 6542] lseek(0, 0, SEEK_END) = 551 [pid 6542] ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff51f3a940) = -1 ENOTTY (Inappropriate ioctl for device) [pid 6542] lseek(0, 0, SEEK_END) = 551 [pid 6542] lseek(0, 0, SEEK_SET) = 0 - not bad behavior, per se, considering what tac is supposed to do, but abnormal, and contrary to what the standard utilities should do. | |
| Mar 17, 2015 at 21:31 | comment | added | mikeserv | @don_crissti - more and more interesting... I'm going to try an strace. Oh wait a minute - tac must be testing stdin to check for a seekable input and rewinding the descriptor - it's the only thing that makes sense to me. I'll check it with strace, though. That, by the way, would be bad behavior, I think. | |
| Mar 17, 2015 at 21:17 | comment | added | mikeserv | @don_crissti - wait, what? tac would have to eat the whole file - just like tail, I would guess - but I would think that if you did the head thing first, you should be able reverse only the latter portion of the file. Is that not what happens? Sorry, this just caught me by surprise. But looking at it more and more and it's an interesting notion. | |
| Jan 27, 2015 at 23:03 | history | edited | mikeserv | CC BY-SA 3.0 | added 266 characters in body |
| Jan 27, 2015 at 21:40 | history | edited | mikeserv | CC BY-SA 3.0 | added 266 characters in body |
| Jan 5, 2015 at 16:46 | history | edited | mikeserv | CC BY-SA 3.0 | added 274 characters in body |
| Jan 5, 2015 at 16:34 | history | answered | mikeserv | CC BY-SA 3.0 |