Making R's paste act more like CONCAT

While vector-friendly, R's paste function has a few behaviors I don't particularly like.

One is using a space as the default separator:

> adjectives<-c("lean","fast","strong")
> paste(adjectives,"er")
> paste(adjectives,"er")
[1] "lean er"   "fast er"   "strong er"  #d'oh
> paste(adjectives,"er",sep="")
[1] "leaner"   "faster"   "stronger"

Empty vectors get an undeserved first class treatment:

> paste(indelPositions,"i",sep="")
[1] "i"
> indelPositions<-c(5,6,7)
> paste(indelPositions,"i",sep="")
[1] "5i" "6i" "7i" #good

> indelPositions<-c()
> paste(indelPositions,"i",sep="")
[1] "i"  #not so good

And perhaps worst of all, NA values get replaced with a string called "NA":

> placing<-"1"
> paste(placing,"st",sep="")
[1] "1st" #awesome

> placing<-NA_integer_
> paste(placing,"st",sep="")
[1] "NAst" #ugh

This is inconvenient in situations where I don't know a priori if I will get a value, a vector of length 0, or an NA.

Working from Hadley Wickham's str_c function in the stringr package, I decided to write a paste function that behaves more like CONCAT in SQL:

library(stringr)
concat<-CONCAT<-function(...,sep="",collapse=NULL){
  strings<-list(...)
  #catch NULLs, NAs
  if(
    all(unlist(llply(strings,length))>0)
    &&
    all(!is.na(unlist(strings)))
    ){
    do.call("paste", c(strings, list(sep = sep, collapse = collapse)))
  }else{
    NULL
  }
}

This function has the behaviors I expect:

> concat(adjectives,"er")
[1] "leaner"   "faster"   "stronger"

> concat(indelPositions,"i")
NULL

> concat(placing,"st")
NULL

That's more like it!

SELinux for enhanced headaches

Security Enhanced Linux (SELinux) is a new extra hidden layer of permissions that makes configuring things more difficult, without ever identifying itself as the culprit - kind of like ACLs but more cryptic. Though it may be more secure, it is not an enhancing experience to deal with, and probably not worth it for the average user.

For example to have Apache serve personal websites (i.e. http://server/~leipzig) it is no longer enough to alter httpd.conf, because you will get mysterious 403 errors until you do this (as others have experienced):

chcon -R -t httpd_sys_content_t /home/leipzig

You forget about this change until xauth starts complaining about stuff for no apparent reason:

/usr/bin/xauth:  timeout in locking authority file /home/leipzig/.Xauthority

so of course you need to do this (thanks Madhav Diwan for this post):

chcon unconfined_u:object_r:user_home_dir_t:s0 /home/leipzig

I have no idea what these things actually mean, nor any real interest in learning. I'm sure this stuff is great for sysadmin cocktail chat but at least for private servers it is just another the brake on the wheel of getting things done. For the time being I have set the level to "permissive", which means it displays warnings but does not interfere, but am leaning toward "disabled" or maybe something else:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=excoriated
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

More on the pros and cons:
http://unix.stackexchange.com/questions/9163/does-selinux-provide-enough-extra-security-to-be-worth-the-hassle-of-learning-set