Arjen
XATTR=/usr/bin/xattr
# Some text files have types and creators, encodings, markers for last
edit location etc.
# If you want to remove one or more of these from your text files you can
use the following functions
# Because xattr will fail if there is no extended attribute we eat ALL
errors including total failure
REMOVE_FILETYPE=sudo ${XATTR} -d "com.apple.FinderInfo" "$(1)" 2>
/dev/null || NOP=42
REMOVE_RESOURCE=sudo ${XATTR} -d "com.apple.ResourceFork" "$(1)" 2>
/dev/null || NOP=42
REMOVE_ENCODING=sudo ${XATTR} -d "com.apple.TextEncoding" "$(1)" 2>
/dev/null || NOP=42
An example of where I use it, is in my function for LaunchDaemons which I
happen to edit with BBEdit nobody needs to know that.
INSTALL_LAUNCHDAEMON=@ \
DEST="${WORK_D}/Library/LaunchDaemons/$(1)"; \
SRC_FILE="${SRC_DIR}/$(1)"; \
sudo ${INSTALL} -m 644 -o root -g wheel "$${SRC_FILE}" "$${DEST}"; \
$(call REMOVE_ENCODING,$${DEST}); \
$(call REMOVE_RESOURCE,$${DEST}); \
$(call REMOVE_FILETYPE,$${DEST});
*WARNING* You will probably need to remove the double quotes. I modified
my version of the luggage to not need backslash escaping on spaces and
other such characters. If you have Makefiles that are dependent on the old
behavior you need to understand that in the examples above backslashes
will be interpreted as regular characters.
--
Geordie
com.apple.quarantine
Hey 2011 Allister who never acted on Geordie's guidance,It was TextMate setting extended attributes on your source files without you knowing. xattr -p doesn't even show/print those, ls -al@ would've told you these two are commonly set by TextMate:com.macromates.selectionRangecom.macromates.visibleIndexAnd if you're REALLY lucky, stuff like this could slip by unnoticed:com.apple.quarantine
So, as Geordie pointed out, xattr -d can strip those and voilà, no detritus in your payload.2014 Allister
On Tuesday, December 20, 2011 3:14:51 PM UTC-5, Allister Banks wrote:Hey folks,
I'm seeing what looks like resource forks make it into the package
when I target /usr/local/sbin. I don't have the files in question
open in an editor, nor am I ditto'ing or overriding the default pack
rules. This may have nothing to do with our bare minimum requirement
of *something* put into the package at that base path, I can't tell.
I tried a slightly older version of Xcode(after using 4.x on my main
machine), the newest luggage.make(I have one from earlier in the
year), and on 10.6.8(instead of my main Lion workstation) with the
same results. Here's a link to what I'm talking about:
https://gist.github.com/cd436cb2add5ee5c504f
No harm no foul, but I'm wondering if we should ameliorate this
somehow.
Thanks,
Allister Banks
@sacrilicious
--
You received this message because you are subscribed to the Google Groups "The Luggage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to the-luggage...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.