Does anyone know how to type the Vulcan salute?

theguardian.com/technology/2014/jun/17/…



But my font won't show it.

@terdon Not showing here either.

Bummer

@slm you had an answer showing a great image of the various bash keyboard shortcuts. Any idea where it is?

is not a square for me... so I presume is showing

@terdon

@slm Ah, yes, thanks. That's the one! I was looking for C-x * to answer this but I found it.

@Braiam Are you seeing the hand?

@Seth raphaelhertzog.com/2012/08/08/…

Per our earlier packaging discussion. Notice item 1?

@FaheemMitha pre-requisites?

@Seth 1. Add .pc to the VCS ignore list

Perhaps you remember us talking about that? I do.

Your Ubuntu guide see to have .pc under version control, if I recall correctly.

@FaheemMitha seems more like kanji

yes, I remember (I just wasn't sure what you considered "step 1")

@Braiam kanji? screenshot

@Seth item 1

> Quilt keeps its metadata in the .pc/ directory, so currently you need to add that to the packaging too. This should be improved in future.

@FaheemMitha s/step/item/

@Seth Right. That thing. Nutty instructions.

Raphael is a DD, used to work on dpkg. He knows his stuff.

I think he doesn't get along with the dpkg maintainer, so he isn't doing dpkg so much any more.

@Braiam That looks terrible.

@Seth i came across it and thought of our conversation. If correcting the Ubuntu guids is an option, do so.

It is an option, but I don't feel confident going about it not really knowing what I am doing yet.

Eventually perhaps..

@Seth What is an option?

Correcting the guides ("If correcting the Ubuntu guids is an option..")

@Seth Oh, I see. Ok.

Whatever you're comfortable with. An alternative is to write to some official channel and complain about it.

I might do that.

You could point to Raphaels writeup.

Yep.

This question: unix.stackexchange.com/questions/165927/… led me to another question: can one remove /, I mean the whole directory tree? I see some problems with that - of course some basic commands as rm itself will be removed too, but they can resist in memory, right? But we will remove kernel, drivers, and all funny stuff as /proc, /sys, etc. Moreover / is a mount point, which may be hard to remove when "busy". Does anybody tried?

@jimmij - this Q comes up from time to time. You cannot remove everything under /. They can exist in memory but many of the things under / are not actually files but interfaces to the running kernel, and are not removable anyways.

You can however render your system unusable by doing something like this.

ding ding ding

guys, suppose one wants to check for all binary files in a directory using find. can one do that?

@FaheemMitha sure, if they can define binary file.

... and by define, I mean in e.g., shell script form, returning true or false

then find -exec THAT-COMMAND {} \; -print will happily do so

@derobert "They"don't have any better idea than I do.

I guess that would be part of my question.

The hard part is identifying "binary file". Classic approaches would be to check the first n characters for non-ASCII, or, I suppose, today non-UTF8.

@FaheemMitha I would probably do something like find . -type f -exec file {} + | grep ELF or similar.

Or, to score pedantry points, all files stored on a computer are binary; therefor, just find -type f :-)

@terdon ok. that's for unix right?

@derobert Probably not that helpful

The easiest way I know to do the 'does it look like text?' text is perl's -T/-B operator

@FaheemMitha Umm. I guess? I don't know if file is available on UNIX but the rest should be fine. If -exec ... + doesn't work on non-GNU find, use -exec ... \;

I'm also not at all sure that all binary executables will have ELF in the output of file. It should do for a start though.

@terdon ok

@terdon That'd depend on the Unix. I don't think you'll find anything else on Linux (a.out is long dead). Other Unices use other formats, though.

@FaheemMitha this is beginning to look like it might be worth a question.

@derobert How about grepping "bit executable"?

@terdon I'm surprised it isn't already asked

@FaheemMitha I can't really think of any reason why one would want to find all compiled executables and exclude scripts.

@terdon ah, well, i have a reason. :-)

to remove binaries from a repos history, when rewriting.

And why would you only want to remove binaries? Why not tgz or .sh as well?

@terdon generally stuff written by a human should stay. machine generated files, no

I see.

@terdon well, you can certainly match on +x. find has options for that.

Of course, but that includes anything with the x bit set.

in general tgz should probably go too

I hope you're using this to generate a list to manually review...

@derobert hypothetically, yes.

@FaheemMitha So that's a binary file as well? Probably the best way to do this would be to run file on all files available, then list the unique results and choose the ones you want to remove.

i mean, i haven't actually done anything. and i'm not sure the owner of the repos in question actually cares anyway

@terdon That would be a lot of files.

@FaheemMitha So? You would have to go through them one by one anyway in order to get the ones you want to delete. So, just do find /path -type f -exec file -b {} + | sort -u. That will give you the file types, there won't be that many. Then, use the file types you want to delete to get the list of files to be removed.

@terdon fair enough

unix.stackexchange.com/questions/165985/… ... wow, that is the poster child for the old "not a real question" close reason

@terdon I'd suggest sort | uniq -c | sort -nr

Unless sort -u got a count option at some point...

(And I just realized I've had ffmpeg peg every core for longer than days. Better part of a year, actually... Well, that might have been mencoder. But...)

@derobert I don't want to count, I want a list of unique results of the file command so I can filter later.

@terdon that is a list of unique results from the file command. Just with a count of the number of files each result applied to. When I have a potentially huge list of things to investigate, I find its often best to start at either the most frequent (biggest impact) or least frequent (most likely to be an error) end.

Ah, yes, OK. Fair enough. I was just going to build a list of what I consider binary, feed that to a script that runs file on each file found and take it from there.

I just find it funny the number of times I've used sort | uniq -c | sort -n ... Especially since that is so inefficient compared to something that was specifically coded to do that. (Not that it normally matters with the input sizes I'm using)

@terdon Note to self: never review the queues after 7/8pm, that's how you get mixed up between what's a question, and what's an answer... Somehow I was sure this was an answer...

@JohnWHSmith Very understandable :) What's more, the edit was actually quite good apart from that. It was quite hard to spot the do he'd added.

Don't worry about it, I just stumbled upon the Q and wanted to point it out to you guys.

Thanks then ;)

This one seems to have solved itself. Should it be closed?

unix.stackexchange.com/q/165900

@FaheemMitha No, it should be answered. Go for it. We like to avoid answers in comments.

@terdon I suggested the original commenter consider it.

Shall I convert that to a "please answer"?

And managed to address the wrong person. Oh, joy. Fixed now.

Heh, as you will. But answers posted as comments are fair game across the network. Feel free to post it yourself.

@terdon Um, ok.

At some point kernel-headers was renamed to kernel-headers. anyone remember when?for debian, i mean

install kernel-headers comes up a lot. do we have a generic/canonical question/answer for this?

> At some point kernel-headers was renamed to kernel-headers. anyone remember when?for debian, i mean