GNU make - conflicting commandline params - takes the first or last one? - gnu-make

If I have make all -j -j1, which parallel option will make take?

Well, you could just try it and see. It would be a lot faster than asking a question on SO and waiting for an answer.
But the answer is, the last one takes precedence.

Related

Weird name in zsh terminal

This question has probably been asked and answered, but I can't seem to find any post that resolve my issue – mostly due to my lack of searching skills. So I apologize if my post is a duplicate and would appriecate if you either refer me to another post or answer my simple question.
When I first open -zsh terminal on my macOS, I am used to seeing the following prompt.
(base) kimsan#Kims-MacBook-Pro ~ %
On rare occasions, however, I see a totally random sequence of characters after #. For example,
(base) kimsan#MDOM10FX ~ %
As I said, the sequence of characters followed by # is – or seem to me, at least – random; thus, changes everytime. Above is just one instance of example.
Why is this???
It has been a while since I first noticed this issue. I freaked out at first thinking that I messed something up with my system memory – which, in hindsight, is not even possible. Now, I think of it as some random inconsequential glitch that don't cause any harm. Nonetheless, I would be more comfortable knowing the cause of such glitch.
Thanks in advance.

IO buffering turn off

Commands which are invoked from LISP are having trouble with buffered IO streams, how to turn it off? I found only flushing functions, which are good for nothing in this situation.
You cannot do that
There is no portable way to turn buffering on and off, and for a very good reason: buffered i/o is orders of magnitude faster.
You should not try to do that
You might be able to find out how to do it in the implementation you use, but it will be a waste of time - you will soon realize that it was a mistake. Please do yourself a favor and do not retrace my steps - I tried that almost 20 years ago.
There is a better way
When you are done writing, just flush the output.
You can encapsulate this using classes or macros, so that no additional typing would be involved.
It is better for many reasons
Please note that the approach I suggest will make your code more readable - it will require you to specify your message boundaries explicitly.
Remember, you write code for others (and yourself 6 months from now!) to read, modify, and debug.
So, I finally found the problem (maybe bug??)
Form looks like this (SBCL API)
(run-program "sudo" '("mv" "foo.txt" "/usr/bin")
:search t
:output t
:input t
:wait t)
This works exactly how I wanted, problem was that instead of t in input and output args, I specified *standard-input* and *standard-output* which caused not proper working of command (if invoked program wanted some input from user like sudo for example).
No idea why, but at least, it works now.

Effective debugging techniques for unix pipes?

I'm very new to unix programming, so please bear with me. :)
I'd like to pass data between two processes. I was going to use named pipes, but read about these "half-duplex" pipes, and it was very intriguing, so I figured that I would give them a try first.
I have two issues with these pipes thus far:
I haven't figured out how to get execlp to run another application from my child process
Even if I could, debugging is tough because I've only been able to set breakpoints in the parent process
I'm sure there are reasons for these issues. I am starting to wonder if it makes sense to just forget about them and just use named pipes so I can debug each application in a separate instance of eclipse.
If there is any relevant information, please let me know. The code I am using is essentially what it found on tldp.org.
EDIT -- I renamed my question to be about unix pipes in general. I had assumed that for named pipes, I wouldn't have to use fork(), but all of the examples I have seen so far require it. So regardless of half-duplex or named pipes, I'm going to need to be able to debug the child process somehow!
EDIT #2 -- this example clearly shows that what I had seen before (on an IBM link) regarding named pipes wasn't necessarily true.
I recommend two tools:
strace -ff should give you a trace of all significant events, allowing you to examine in detail what's going on, namely, all reads and writes;
lsof allows you to dump file descriptors of involved processes, clearly showing what is connected to what else and, in particular, if you forgot to close() some descriptors and the whole thing deadlocks.

Looking for examples of command chaining in Parsley 2.4

In order to help me understand, I'm looking for examples of command chaining in Parsley. What I mean by command chaining is when one command returns a result that is then immediately used to initiate another command. I ask this question here because the parsley forums have been down for 2 days.
Have you had a look at the Spicelib Task Framework? It should do everything you want to, and it has some good example.

Possible to fork a process outside from it?

Well, it is obvious, let's say we have two processes A and F. F wants to fork A when it has the CPU control (and A is suspended since CPU is on F).
I have Googled however nothing related showed up. Is such a thing possible in Unix environments?
There is definitely no standard and/or portable way to clone a process from the outside but depending on the OS, there are certainly possible ways to divert a process from its task and force it to clone itself or do whatever you want.
I don't think it's a good idea in any way, but it may be possible for process F to attach to A using a debugger interface such as ptrace. Doing something like suspending the target process, saving its state, diverting the process to run fork, then restoring its original state.
It should be noted that your cloning process will probably need to handle some odd cases around threads and the like.
No it's not possible.
The fork() system call makes a copy of the parent, so if you call fork() in the F process, the child will be a copy of F, there's nothing you can do to change this behavior.
The reason this is not possible is because, normally with fork(), there is exactly one difference to start out with between the two processes: the return value of the fork() call itself. Without such a call inside the code of A, there is no way for the processes to have any difference between them, so they would both be doing exactly the same thing, when normally with you want one of the processes to start doing something different.
How exactly do you think what you want to do should work?
No, this would be a huge security hole that would result in the leakage of sensitive information if it were possible.
At best, you could setup a signal handler in the parent process that would fork(2) off a child (maybe exec(2) a pre-configured child process?).
I think you would be better served by looking in to message passing between two processes that have CPU affinity setup, but even then, I think the gains would be nominal (over-optimizing a problem?).
http://www.freebsd.org/cgi/man.cgi?query=cpuset&apropos=0&sektion=0

Resources