Rote Administrators, Copy And Pasters extraordinaire.
http://thejh.net/mis...rminal-copy-paste
Careful, collect and verify. Always. (right Naperville boy?)
How I wish thee were not around...
Rote Administrators, Copy And Pasters extraordinaire.
http://thejh.net/mis...rminal-copy-paste Careful, collect and verify. Always. (right Naperville boy?) --
greg@gregfolkert.net PGP key 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C |
|
notepad++ is your friend for copypasta to commandline
or vi of course with :set list running
Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free American and do not reflect the opinions of any person or company that I have had professional relations with in the past 57 years. meep
|
|
Found a limitation of Notepad++
Its support of editing columns is very, very limited. (E.g. you can paste a single word into a column, but not a column of data.)
UltraEdit (for Winders) still has a place in my toolkit. YMMV. Cheers, Scott. |
|
Classic interview questions
What is the editor of choice you use? (don't care unless they say ed,edlin, or sed).
Have you ever worked with data in the editor? (everyone says yes) How do you do a columnar cut&paste in it? If they say anything other than a series of steps (or asked me to clarify) (I'd memorized for about a 1/2 a dozen editors at that point) then it was a red flag. |
|
I always use regexes in vim ... would that be a flag?
I know vim does columnar cut/paste, but I don't typically work with fixed-width data, so it didn't come up much.
--
Drew |
|
Possibly
But it would open up the discussion for how you do it alternatively, and I'd say you were using it as a programmable editor at that point, and accomplishing the task.
I might tell you how to do it in your editor of choice, though, to earn a few "Yeah, I know shit and you don't points, and this is a technical interview, so start shining". Note: This will only work with gvim. The functionality showed up when Brad Mooloneier? (not looking it up) went from character mode (others ways, I'm giving you the visual path) to graphical. So don't use it in default unix vi (it sucks, install vim/gvim as soon as you experience a system that has it). :set nowrap (if wrapped) If it is tab delimited data, set your tab stops to wider than the widest field. :set ts=100 (or whatever) ^V (highlight phase). Move around with cursor. y (there are many possible alternatives here since you get to choose any of the named alphabetic (you got 26 you play with, use them well) cut/copy buffers in vim, but a lowercase 'y' will simply throw it into the default buffer) At that move, hit 'p', and watch the magic. Note: Many settings will affect how it does it, in code VS data and if it is in any type of autoindent mode. I had a boss that was an old "typsetter". You met him at the wedding. He had a piece of the Village Voice. Really. He used workstations for layout which had an editor. This editor then got ported to MS-DOS and others. xywrite. He would do the most ridiculous transformations via a series of search and replaces. It was amazing. And error prone. My 1st task was to remove all macros he ran and put them in a coded production script. |
|
Meh.
I do data work in Emacs all the time and as far as columnar moves go couldn't tell you anything beyond "go look it up on teh Googlez".
Ask me to show you how to transform something in a list of files, though, and yeah I'll show you some shit... ;-) Regards,
-scott Welcome to Rivendell, Mr. Anderson. |
|
Yes, we've had this discussion
Doesn't matter.
And not like I'm recruiting or hiring right now, so it really doesn't matter. |
|
I don't want anything to do with excel
have someone else do it, good bye and thanks for the opportunity.
Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free American and do not reflect the opinions of any person or company that I have had professional relations with in the past 57 years. meep
|
|
Heh, in all honesty
I'd answer no to question two, because if I need to do stuff with data, I prefer grep/awk/sed... and enough so that I've not actually done any major data manipulation in an editor. It usually ends up being faster, and after you do a run or two with some small data subsets to make sure you've got it right, it's a lot less prone to error.
|
|
Oh, how 70s/early 80s of you
Give perl a shot.
I lived in grep/awk/sed/tr/etc piplines for about 5 years before moved to perl for 90% of those tasks. |
|
The thing for me
is that almost all of it is grabbing stuff out of mail logs so I can figure out which hosts/nets to tell to go fuck themselves. It works, it's fast, and I can have it output a command line which I can ssh on over to our firewall to run. Given that the repeatability of each of them is pretty low (and I've aliased the little routines I use a lot) it's a reasonable approach.
If I was doing stuff that ran over and over again on fresh data sets that basically resemble their forebears, I'd probably use javascript; we have a good intepreter and it's a lot more like the languages I learned on. Think admin tool, rather than data analysis. |
|
Hehe
Think admin tool, rather than data analysis.
https://www.google.c...ss+army+chain+saw It actually STARTED as a replacement for each of those tools you mentioned, for admin purposes, and did each very well, yet added great glue to bring them altogether. |
|
Nice turn of phrase :)
|
|
I'd rather use something readable, like Python
Faster, explicit, and maintainable.
Yes, I know one can write maintainable Perl. It's very easy to *not* write maintainable Perl, however, and I know enough other developers that my own selfishness prefers them to use something else. Regards,
-scott Welcome to Rivendell, Mr. Anderson. |
|
Or Ruby.
Just Add Story http://justaddstory.wordpress.com/
|
|
Note where I said "explicit"
Ruby suffers from the same issue Perl does: lots of magic and implicit behavior. The libraries are typically quite slow as well.
Regards,
-scott Welcome to Rivendell, Mr. Anderson. |
|
Sad, but I agree
But that's for REAL programmers.
I have no idea how well it does for 1-off sysadmin usage. As the years go on, I am reminded of bt's standard phrase. Perl can do anything, but it is always the wrong tool for the job. And then he'd solve the problem in perl due to library availability and his own coding comfort. Have the libraries caught up? |
|
I'm using it to build a complicated site right now
Not sure what libraries might be missing, but there are some ridiculously complex things out there on Python right now.
I'm not sure why you would say Python is for real programmers if Perl is an alternative. Kids learn Python... not Perl. Regards,
-scott Welcome to Rivendell, Mr. Anderson. |
|
You misunderstood
Perl grew organically from a really complex group of starting ideas, ie: the various command line programs he was trying to do without. This means lots of little rules to keep track of. I do not claim this is good.
Python has a logical design to start off with. This design supports real programs. Not having real experience in it, I can't say past that. Since perl's "design" is mostly slapping sysadmin pieces together, it SHINES for those tasks, and can be abused for others. If someone already understands the bash/awk/grep/sed/tr/cut/paste pipelines, then pretty much everything they are used to doing on the command line can be written in a very short perl script, but with decent error checking and error recovery and logging, all the shit that is awful in standard shell programming. If someone wants to argue that, I'd like them to play with the 'trap' in shell scripts to handle error conditions in a complex multi-script system. While simultaneously checking return codes from programs called and remember zero, ie: false, is good. And then realizing you gotta deal with the shift operator to deal with anything else. While pulling output from both STDOUT and STDERR (oh the fun of multiple substituted redirection to put things in log files. And processing the STDOUT at the same time in the next program. And using the 'test', ie: '[' program to handle the various inequalities. And abusing the shell to do decent math at the same time. And cut/paste pipelines are awful. I found it amusing that jake's default thought concerning perl was for data processing rather than admin tasks. Most admins will NEVER be "real" programmers. It is a different mindset. But they need programming tools for short tasks. So perl took shell style command line programming brevity and added some nice wrappers around it. So it is a short jump for sysadmins to use it for their tasks, while not being required to adhere to a stronger "programming" philosophy. Sure, this annoys "real" programmers, but it is really the core use and "design" philosophy of the language. |
|
Beat me to it...
I was just on my way to the Security forum to post this.
Regards,
-scott Welcome to Rivendell, Mr. Anderson. |