What would this command do if run in UNIX? - unix

I saw this command posted somewhere, :(){ :|:& };:
What would it do if I ran it in UNIX, I don't feel like trying myself in case it does something bad

This is a fork bomb and it is very bad.
It will spawn many many processes, the number growing exponentially as each process spawns two more. They will clog your system until it falls over.

Don't run it. Its fork bomb. it will bring down your system.
From wikipedia :
/- Define the function ':' without any parameters '()' as follows:
| /- Beginning of function-block.
| | /- Load a copy of the function ':' into memory ...
| | |/- ... and pipe its output to ...
| | ||/- ... another copy of the ':'-function, which has to be loaded into memory.
| | ||| (In other words, ':|:' loads two more copies of ':', thus causing a chain-reaction)
| | |||/- Disown the functions (make them a background process), so that the children of a parent
| | |||| will not be killed when the parent gets auto-killed.
| | |||| /- End of function-block.
| | |||| |/- End of definition.
/-\| |||| ||/- Execute the function ':'. The chain-reaction begins.
:(){ :|:& };:
Here is the link http://en.wikipedia.org/wiki/Fork_bomb

Related

Is there a way to verify that given targets are marked .PHONY in makefile?

I am having a bunch of make files in different projects that I want to verify against some criteria of all targets or a list of targets are marked .PHONY.
I am not sure whether such a test already exists or if it is possible to introduce one?
As far as I'm aware, no.
make / gmake itself has no functionality to print that.
However, it's easy to find out yourself from make's dependency/target database output:
make -nsp --no-print-directory --always-make
||| | |
||| | run, no matter whether
||| | parts have already been built
||| |
||| don't print the directory structure
|||
||\--- print the database
|\---- be silent, otherwise
\----- don't actually build anything
prints what make figured out are all targets.
make -nsp --no-print-directory --always-make | grep -E '^\.PHONY:'
prints all the targets that are dependencies of the .PHONY "pseudo"-target.
You can then do with that list whatever you want :)

Getting around borrowing as mutable after immutable [duplicate]

There are several wrapper types in the Rust standard library:
The cells in the std::cell module: Cell and RefCell
The reference-counted wrappers, like Rc and Arc.
The types in the std::sync module: Mutex or AtomicBool for example
As I understand it, these are wrappers which provide further possibilities than a simple reference. While I understand some basics, I cannot see the whole picture.
What do they do exactly? Do cells and reference-counted families provide orthogonal or similar features?
There are two essential concepts in Rust:
Ownership,
Mutability.
The various pointer types (Box, Rc, Arc) are concerned with Ownership: they allow controlling whether there is a single or multiple owners for a single object.
On the other hand, the various cells (Cell, RefCell, Mutex, RwLock, AtomicXXX) are concerned with Mutability.
The founding rule of Rust's safety is Aliasing NAND Mutability. That is, an object can only be safely mutated if there is no outstanding reference to its interior.
This rule is generally enforced at compile time by the borrow checker:
if you have a &T, you cannot also have a &mut T to the same object in scope,
if you have a &mut T, you cannot also have any reference to the same object in scope.
However, sometimes, this is not flexible enough. Sometimes you DO need (or want) the ability to have multiple references to the same object and yet mutate it. Enter the cells.
The idea of Cell and RefCell is to permit mutability in the presence of aliasing in a controlled manner:
Cell prevents the formation of reference to its interior, avoiding dangling references,
RefCell shifts the enforcement of Aliasing XOR Mutability from compile time to runtime.
This functionality is sometimes described as providing interior mutability, that is where an object which otherwise looks immutable from the outside (&T) can actually be mutated.
When this mutability extends across multiple threads, you will instead use Mutex, RwLock or AtomicXXX; they provide the same functionality:
AtomicXXX are just Cell: no reference to the interior, just moving in/out,
RwLock is just RefCell: can obtain references to the interior through guards,
Mutex is a simplified version of RwLock which does not distinguish between a read-only guard and write guard; so conceptually similar to a RefCell with only a borrow_mut method.
If you come from a C++ background:
Box is unique_ptr,
Arc is shared_ptr,
Rc is a non thread-safe version of shared_ptr.
And the cells provide a similar functionality as mutable, except with additional guarantees to avoid aliasing issues; think of Cell as std::atomic and RefCell as a non thread-safe version of std::shared_mutex (which throws instead of blocking if the lock is taken).
Thanks to Matthieu's good answer, here is a diagram to help people to find the wrapper they need:
+-----------+
| Ownership |
+--+--------+ +================+
| +-Static----->| T |(1)
| | +================+
| |
| | +================+
| +-----------+ | Local Val| Cell<T> |(1)
+-Unique-->| Borrowing +--+-Dynamic---->|----------------|
| +-----------+ | Ref| RefCell<T> |(1)
| | +================+
| |
| | +================+
| | Threaded | AtomicT |(2)
| +-Dynamic---->|----------------|
| | Mutex<T> |(1)
| | RwLock<T> |(1)
| +================+
|
|
| +================+
| +-No--------->| Rc<T> |
| | +================+
| Locally +-----------+ |
+-Shared-->| Mutable? +--+ +================+
| +-----------+ | Val| Rc<Cell<T>> |
| +-Yes-------->|----------------|
| Ref| Rc<RefCell<T>> |
| +================+
|
|
| +================+
| +-No--------->| Arc<T> |
| | +================+
| Shared +-----------+ |
+-Between->| Mutable? +--+ +================+
Threads +-----------+ | | Arc<AtomicT> |(2)
+-Yes-------->|----------------|
| Arc<Mutex<T>> |
| Arc<RwLock<T>> |
+================+
In those cases, T can be replaced with Box<T>
Use AtomicT when T is a bool or a number
To know if you should use Mutex or RwLock, see this related question.

Jq using contain with multiple match conditions

I have json file with multiple object Id's and I need a query that excludes different ids based on naming conventions. These are essentially OR's. I thought I had it with this query but they are still appearing in the output.
If I run the query with them separately I can get it to work, but I need to add a large list.
Works
cat file.json | jq '.interface[] | select(.description | contains ("VLL") | not )'
Not working
cat file.json | jq '.interface[] | select(.description | contains ("VLL"|"2002089"|"otherstuff" ) | not )'
Ive tried a few different ways with commas and quoting but no luck.
Am I far off?
I also plan to run this in bash script if that help(probably makes worse)
Thanks
Am I far off?
If you use test/1 instead of contains, and make corresponding adjustments, no:
.interface[]
| select(.description | test ("VLL|2002089|otherstuff" ) | not )
The argument of test is interpreted as a regex. There are of course alternatives, but if using a regex is appropriate, then test would be suitable.
Blacklist of strings
If you have a blacklist of strings and want to use string equality as the criterion, consider:
["VLL","2002089","otherstuff"] as $blacklist
| .interface[]
| select(.description | IN($blacklist[]) | not)

Arguments gone missing for robot-framework

The below is rewarded with a complaint that Remove Directory requires 1 or 2 arguments and I gave it none. I'm using 2.6.3, and dcsLshLocation is a variable (and adding an x in front doesn't change the error). I'm using the Java version of all this.
*** Settings ***
| Documentation | http://jira.basistech.net:8080/browse/JEST-226
| Resource | src/main/resources/jug-shared-keywords.txt
| Force Tags | integration |
| Suite Precondition | Run Keywords |
| | ... | Validate SUT Installations |
| | ... | Launch Derby Server |
| | ... | Copy file ${jddInstallDir}/conf/jdd-conf-basic.xml to ${jddInstallDir}/conf/jdd-conf.xml
| | ... | Remove Directory | ${dcsLshLocation} |
| Suite Teardown | Run Keywords | Shutdown Derby
| Test Timeout | 20 minutes
When this question was originally written, Run Keywords could only run keywords that do not take arguments. That is no longer true. From the documentation:
Starting from Robot Framework 2.7.6, keywords can also be run with arguments using upper case AND as a separator between keywords. The keywords are executed so that the first argument is the first keyword and proceeding arguments until the first AND are arguments to it. First argument after the first AND is the second keyword and proceeding arguments until the next AND are its arguments. And so on.
The code in the question can thus be expressed like this:
| Suite Precondition | Run Keywords |
| | ... | Validate SUT Installations
| | ... | AND | Launch Derby Server
| | ... | AND | Copy file ${jddInstallDir}/conf/jdd-conf-basic.xml to ${jddInstallDir}/conf/jdd-conf.xml
| | ... | AND | Remove Directory | ${dcsLshLocation}
The following is the original answer to the question, which others may still find useful. It is still relevant for versions of robot framework prior to 2.7.6.
When you use Run Keywords, you cannot run keywords that take arguments. Admittedly the documentation is a bit unclear, but this is what it says:
User keywords must nevertheless be used if the executed keywords need
to take arguments.
What it should say is that, when you use Run Keywords, each argument is the name of a keyword to run. This keyword cannot take any arguments itself because robot can't know where the arguments for one keyword ends and the next keyword begins.
Remember that ... simply means that the previous row is continued on the next, so while it looks like each row is a separate keyword with arguments, it's not. You example is the same as:
| Suite Precondition | Run Keywords |
| | ... | Validate SUT Installations |
| | ... | Launch Derby Server |
| | ... | Copy file ${jddInstallDir}/conf/jdd-conf-basic.xml to ${jddInstallDir}/conf/jdd-conf.xml
| | ... | Remove Directory |
| | ... | ${dcsLshLocation} |

Can ECB be restricted to "take over" only the current buffer when it's activated?

From the get go: sorry if I'm not using the proper emacs terminology -- I'm relatively wet behind the ears in the emacs world.
Most of my work in emacs is for programming R, and I'm using ESS and ECB to do so quite happily. I'd like to build a custom ECB layout which uses the entire bottom of the screen as my R console, while putting some ECB-specific buffers on the left.
Using ECB-esque layout diagrams, I'd like my layout to look like pretty much exactly like "left13", except I'd like the entirety of the "compilation" buffer to be my running R console (or any shell, for that matter):
-------------------------------------------------------
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| Directories | Edit |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
-------------------------------------------------------
| |
| R Console |
| |
-------------------------------------------------------
If I can just split my buffer in two (vertically), then call ecb-activate from the top buffer (and not allow it to touch my bottom buffer), I'm imagining it could work (hence the subject of my question).
That doesn't work, though, and I don't know how to get an entier "bottom pane" out of a layout to work in the way I like using trying to use ECB's customize layout functionality.
Does anybody know if/how I can do this?
Short answer: No.
Longer answer: Unfortunately, ECB completely takes over Emacs "window" management at a very low level. So it's all or nothing. You can't comfortably combine it with regular window splitting. What you might be able to do, is to adjust the layout ECB gives you or to program a custom layout. (Some assembly required.)

Resources