interesting use of bash's exec function over at Code Golf: codegolf.stackexchange.com/a/16529

Hey there. Any linux hackers around?

(folks who do kernel development ?)

@gideon don't ask to ask a question. just say what you want and someone will come by and read it later

Alrighty

and I don't believe any regulars in this room are kernel hackers. why do you ask?

(most people are professional sysadmins)

sorry. Got caught up in something.

@strugee

I'm getting into kernel development, I've been playing with toy OS's and what nots and now got a book on linux kernel development.

The painpoint from what I've read for far seems to be if I checkout and build my kernel, setting it up for my machine to work seems dicey. There are articles geared towards specific distros.

I'm currently running Fedora so I wanted to ask if anyone is doing kernel dev on fedora and if there are any snags I should watch out for.

I dunno. it doesn't seem that bad to me

@terdon The general consensus and status quo on SE (including chat) in that it ought to stay clean and professional. Sure the guard is down a bit on chat but that's no reason to encourage abuse.

@Caleb I was not encouraging abuse. I just find it silly to be extreme with as mild a word as shit. Especially given the language commonly used in the larger chat rooms. There was also a meta post about this at some point and the consensus seemed to be "don't overdo it, but we don't really care".

@Caleb have you seen the SF chat?

@gideon - Linus uses Fedora so you should be fine.

@slm I think he was looking for kernel gurus here.

@terdon - I was answering this Q: "I'm currently running Fedora so I wanted to ask if anyone is doing kernel dev on fedora and if there are any snags I should watch out for"

I've compiled the kernel many times from scratch and have made changes in the form of my own patches and/or the application of other people's patches, so I would say I'm qualified to help him to a point 8-)

He looks to be just getting started anyway, so his Q's most of us will be able to help him with.

@Gilles What about SF? I've actually never been in that room.

@slm their chatroom is pretty intense, as in intensely rude

generally speaking, the vocal people on SF are assholes and proud of it

@Gilles don't you mean aholes or a**holes?

@terdon no, if I'd meant that I'd have written that

bad Gilles...

:)

@Gilles @terdon - if you've ever met sysadmins, that's normal. Not that I agree with the behavior but just about everyone of them is like that.

@slm I have. In my experience, assholery doesn't correlate with competence.

It does correlate, just negatively.

@Gilles Agreed. Drs. are the same, I work with them and I think the arrogance one gains from knowing things that others do not, is what fuels this.

Doctors are the WORST! Believe me, I'm a biologist and I have to deal with the ignorant, arrogant twits way too often.

Doctors are simply glorified mechanics who have a vague idea of how a single, specific machine works and sell themselves as erudite.

@Gilles Yes. I also know it's splitting their community apart and there have been some crackdowns and "how to fix it" has been a subject of conversation.

I've had several sit there and tell me it's the computer that's wrong when inputting passwords. They were serious. They never make a mistake.

@terdon whereas sysadmins have no idea of how many, diverse machines work and sell themselves as erudite?

Curbing it before it settles in as a pattern is far easier than cleaning house afterwards.

@Caleb - agreed, it's really unnecessary here anyways

@Gilles well, at least they can work on different hardware, MDs only deal with one set of hardware and they barely understand it. Admittedly, it is a horribly complex system and nobody understands it any better than they do. It's the arrogance that bugs me. Especially when I find myself needing to explain very basic concepts of genetics and DNA regulation when talking to MDs.

@terdon I never got the point of obfuscating "bad" words.

@Caleb neither have I, it seems to defeat the purpose. Either be profane or don't be. writing s*it is just silly.

@terdon S*It sounds like something Samsung would advertise as a feature on Galaxy phones.

Heh :)

@derobert lol

Anyone have any idea about this?

Looks like an ssh message, not the shell's but the OP told me in chat that his ~/.ssh/config is essentially empty.

He's trying to track down why he gets these message printed upon ssh login :

Agent pid 2117
/home/user/.ssh/internal/2013-07-29: No such file or directory
/home/user/.ssh/deployed/2013-07-29: No such file or directory
Identity added: /home/user/.ssh/external/2013-07-29 (/home/user/.ssh/external/2013-07-29)

@terdon “Agent pid” is from starting ssh-agent. Then something happens (probably a custom script), then ssh-add

grep ssh-agent .*

or could be in /etc (e.g. /etc/profile)

@Gilles OK, I'll tell him to grep for "ssh-agent" in the various .profile files

I'd grep for those files that aren't being found...

Surely the name is referenced somewhere.

@derobert which files?

The two that he gets 'no such file or directory' for

The only ones not being found are things like ~/.bash_login which is no big deal

/home/user/.ssh/internal/2013-07-29: No such file or directory
/home/user/.ssh/deployed/2013-07-29: No such file or directory

... those

I have no idea what that grep_bash does, if it looked in all the right places

There are a few places besides the typical profile files, that are specific to ssh. All of them are in ~/.ssh or /etc/ssh, I think.

Note that could be ~/.ssh on the client too.

I guess there could be custom stuff in pam as well

@derobert the grep bash is just a little function of mine:

grep_bash(){
  for f in  ~/.bashrc ~/.profile ~/.bash_profile ~/.bash_login \
            /etc/profile /etc/environment;
  do
    [ -e $f ] && grep -H "$@" $f;
  done
}

Ah, yeah, that doesn't search everywhere it could be then.

I'd start with a grep of $HOME

at least, if the two obvious ssh places don't find it

@derobert if you have nothing better to do, come join us here: chat.stackexchange.com/rooms/12238/…

He's given a lot more info

There is an .sshrc file being read that I'm not sure about

I haven't checked what he's added in chat

derobert figured it out @Gilles, it turns out it came from /etc/ssh/sshrc.

build/%: %.d $(COMBINE) $$(wildcard $$(addsuffix .d,$$(subst build/,,$$<))/*)
	@mkdir -p build
	if [ -e "$@" ]; then chmod u+w "$@"; fi
	$(COMBINE) "$(HOSTNAME)" $(wordlist 3,66535,$+) > "$@"
	chmod u-w "$@"

~/.%: build/$$(subst /,\#,$$(subst $(HOME)/.,,$$@))
	mkdir -p $(dir $@)
	$(ISL) $(FORCE) "$<" "$@"

/me attempts to scare the channel away

yes, $(patsubst …) would be better there and is documented to work there. But it doesn't.

@derobert you won't scare me, I've written worse GNU makefiles than that.

Granted, I had trouble reading them afterwards

Hah, yeah

one of those vim weird cases

@Braiam here's a nickel, kid. Take it and get a real editor.

There, my xterm weirdness

/me starts digging through a strace

hmmm, xterm/uxterm difference? Are they started under the same name and class?

Yep. Found the difference in the strace...

khotkeys is starting the xterm with SIGHUP blocked

Wonder how the #@!(# to fix...

You can make your own uncloseable xterms by running trap -- '' SIGHUP ;-P

Unfortunately, bash doesn't see the signal at all, so I can't just do a trap -- 'exit' SIGHUP to fix

@Gilles that 'yep' is yes, started under the same name/class

xterm & uxterm & lxterm all behave the same here, at least in this respect

@Gilles what's your personal preference?

@Gilles you didn't actually answer. you just said "I know which one I'd pick"

@strugee oh, come on, it's transparent

@strugee - he's a gedit man

lol

Damn SSDs always breaking C-x M-c M-butterfly.

heh. gedit

or Pluma (MATE's fork of gedit 2), depending on how Gilles feels about GNOME 3

Filing a bug, get to answer my own question.

Wonder if there is a workaround. Not sure if there is a shell command to unmask signals

@derobert doesn't trap - HUP work?

Not in the shell running in the xterm

it probably unmasks it for the shell, but not the xterm. That'd be my guess

@derobert why would you need to unmask it in xterm?

doesn't that button send a DELETE (IIRC) X11 message?

actually, it seems not to unmask it at all... if I start another xterm, it doesn't work there either...

@Gilles yeah, it clearly sends some X11 message, from the strace, which then gets xterm to do a kill to raise SIGHUP

but bash isn't receiving that sighup, at least according to strace

even after trap - HUP

or after trap -- 'echo hi' HUP

IIRC trap somecommand HUP doesn't do anything if the signal is ignored, but trap - HUP unignores it

strace tells me it doesn't actually do anything useful, it's leaving HUP blocked

Interestingly, if I dump out perl's %SIG, perl doesn't realize its ignored

But it does if I ignore a different signal from bash's trap

There must be multiple ways to ignore a signal...

@derobert and is it actually ignored?

rt_sigprocmask(SIG_BLOCK, [INT], [HUP], 8) = 0
rt_sigprocmask(SIG_SETMASK, [HUP], NULL, 8) = 0

@Gilles it seems bash is using rt_sigaction to set signals to SIG_IGN, so trap ignores signals, not masks/blocks them. That makes sense, when you clear one with trap, it isn't pending...

So, time to try a little bit of C to confirm.

#include <signal.h>
#include <stddef.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
	sigset_t set;

	if (argc < 2) {
		fprintf(stderr, "ERROR: Expected at least a command to run\n"
				"\n"
				"USAGE: %s command [arguments]\n",
				argv[0]);
		exit(EXIT_FAILURE);
	}

	sigemptyset(&set);
	sigaddset(&set, SIGHUP);
	sigprocmask(SIG_UNBLOCK, &set, NULL);

	execvp(argv[1], argv+1);
}

This trivial C program can be used to spawn an xterm that properly exits.

Or you can do exec ./unblock-hup bash and get a bash that'll exit

Which, if you've already pressed the x, immediately exits, as expected...

So I have a workaround to add to my answer now.

/me wonders why debbugs still hasn't given me my bug number, or done anything with the report, its been over half an hour...

Hah, not only did I get a working close button out of that, I got a hat :-P

@derobert does it do something different than sh -c 'trap - HUP; exec "$@"'?

@Gilles yes

hmmm

did you try bash -c 'trap - HUP; exec "$@"'? or ksh -c 'trap - HUP; exec "$@"'

different shells handle signals a bit differently

True, it might work in a different shell...

But they probably all ignore signals by ignoring them, not blocking them. The signal mask is "don't deliver it now, but deliver it later"

Which isn't a very effective way to ignore signals...

Unless you leave it blocked forever.

bash does rt_sigprocmask(SIG_BLOCK, NULL, [], 8) when it starts

three times (so you know it's true?)

then, with trap - HUP, it calls sigaction to set SIGHUP to SIG_IGN, then again to SIG_DFL

@gideon - if you get to a point where you want to work on making a basic device driver then this series is for you: linuxforu.com/tag/linux-device-drivers-series/page/2

@derobert - is it true that no devices will show up under /dev unless there's a corresponding rule that creates them via udev? I understand we could run mknod manually, so let's ignore that for the sake of this Q

@slm I think so. Its possible that there may be some special cases hardcoded in somewhere—e.g., maybe for something like /dev/null

yeah i'm trying to help out on this Q unix.stackexchange.com/questions/107294/…

want to make sure i have my facts straight

i'm confused since dmesg shows sdb and adb1 so the device is getting detected but there isn't a corresponding /dev for it

weird, yeah, seems like /dev/sdb and /dev/sdb1 ought to be there, unless maybe udev is failing somewhere

e.g., maybe a drive probe is timing out

yeah I thought it was weird too, the device showing up in dmesg is usually a good indicator that udev has detected it

wow, got a response to that debian bug report...

apparently, it might actually be an nVidia bug(!)

writing a quick reply, got to run...

ok, quick question

grep considers @ to be whitespace, why, and how do i ignore it?

abc@ is caught using grep abc textfile.txt