We got rejected by Apple. Happens all the time right? But this time we are a bit stumped. The old ways of sussing this out aren't producing a clue to the solution.
From Apple:
5 PERFORMANCE: SOFTWARE REQUIREMENTS
Performance - 2.5.1
Your app uses or references the following non-public APIs:
transition:didComplete:
The use of non-public APIs is not permitted on the App Store because
it can lead to a poor user experience should these APIs change.
This app has been around half a decade and over the years, mostly due to business needs, it has a lot of references to 3rd party SDKs. This is where we are focusing our attention, but the trail dries up quick and is turning into a massive removal of everything until we find the pieces that include this old code.
What we know is it is not a symbol, otool and nm don’t find anything. strings does locate a match (1 time in the debug build and 2 times in our final release build if that is a clue or makes a difference.) This would appear to be a call is UIKit so I assuming that would not be the case.
Does anyone have any suggestions on how to proceed?
We're going through every archive/lib/binary we can find referenced in the project and doing string searches. If that fails we are about to rip every SDK out and do a destructive binary search to find the guilty party... If there was a hot tip on how to solve this I am all ears!
Here is the command line output (strings, otool, and nm):
Dev-MBP:helloworld.app codemonkey$ otool -ov helloworld | grep -C 10 "transition:didComplete"
Dev-MBP:helloworld.app codemonkey$ nm helloworld | grep -C 10 "transition:didComplete"
Dev-MBP:helloworld.app codemonkey$ strings helloworld | grep -C 3 "transition:didComplete"
destinationLayout
prepareTransition:
performTransition:
transition:didComplete:
destinationViewController
sourceViewController
isViewTransition
--
--
destinationLayout
prepareTransition:
performTransition:
transition:didComplete:
destinationViewController
sourceViewController
isViewTransition
Dev-MBP:helloworld.app codemonkey$ strings helloworld | grep "transition:didComplete"
transition:didComplete:
transition:didComplete:
Dev-MBP:helloworld.app codemonkey$
The lib containing the string "transition:didComplete:" was coming from the 4.x Google Play Games libs for c++. We also found it in the latest 5.1.1.
The command/script I ran to find this string inside of a file is probably the most useful part of this answer:
Dev-MBP:helloworldproj codemonkey$ find . -type f | while read i; do grep 'transition:didComplete' "$i" >/dev/null; [ $? == 0 ] && echo $i; done
Run this from the root of your iOS project (assuming your frameworks you added are all under that directory)
We can now deliberate on the most efficient way to write this command. I've already had one suggestion:
From a friend:
Naturally, it could be improved upon. The -l option to grep does the
same thing, so ...
find . -type f |
while read i
do
grep -l 'transition:didComplete' "$i"
done
Related
The asterisk or star tells the engine to attempt to match the preceding token zero or more times. The plus tells the engine to attempt to match the preceding token once or more.
Based on the definition, I was wondering why the plus sign returns more matches than the asterisk sign.
echo "ABC ddd kkk DDD" | grep -Eo "[A-Z]+"
returns
ABC DDD
echo "ABC ddd kkk DDD" | grep -Eo "[A-Z]*"
returns
ABC
As far as I can tell, it doesn't. With GNU grep versions 2.5.3, 2.6.3, 2.10, and 2.12, I get:
$ echo "ABC ddd kkk DDD" | grep -Eo "[A-Z]+"
ABC
DDD
$ echo "ABC ddd kkk DDD" | grep -Eo "[A-Z]*"
ABC
DDD
Please double-check your second example. If you can confirm that you get only one line of output, it might be a bug in your grep. If you're using GNU grep, what's the output of grep --version? If not, what OS are you using, and (if you know) what grep implementation?
UPDATE :
I just built and installed GNU grep 2.5.1 (the version you're using) from source, and I confirm your output. It appears to be a bug in that version of grep, apparently corrected between 2.5.1a and 2.5.3. GNU grep 2.5.1 is about 12 years old; can you install a newer version? Looking through the ChangeLog for 2.5.3, I suspect this may have been the fix:
2005-08-24 Charles Levert <charles_levert#gna.org>
* src/grep.c (print_line_middle): In case of an empty match,
make minimal progress and continue instead of aborting process
of the remainder of the line, in case there's still an upcoming
non-empty match.
* tests/foad1.sh: Add two tests for this.
* doc/grep.texi, doc/grep.1: Document this behavior, since
--only-matching and --color are GNU extensions which are
otherwise unspecified by POSIX or other standards.
Even if you don't have full access on the machine you're using, you should still be able to download the source tarball from ftp://ftp.gnu.org/gnu/grep/ and install it under your home directory (assuming your system has a working compiler and associated tools).
This is basically the same issue as in mingw ld cannot find some library which is exist in the search path, MinGW linker can't find MPICH2 libraries - and I'm aware that there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW - but I couldn't find anything that explains how I can troubleshoot.
I am building a project with a huge linker command like (via g++) on MinGW, in a MSYS2 shell (git-bash.exe). The process fails with, among others:
/z/path/to/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lssl
I add -Wl,--verbose to the g++ linker call (to be passed to ld), and I can see for the -L/z/path/to/libs/openssl/lib/mingw -lssl:
...
attempt to open /z/path/to/libs/openssl/lib/mingw/libssl.a failed
...
/z/path/to/libs/openssl/lib/mingw/ssl.dll failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
But this is weird, because the file exists?
$ file /z/path/to/libs/openssl/lib/mingw/libssl.a
/z/path/to/libs/openssl/lib/mingw/libssl.a: current ar archive
(... and it was built with the same compiler on the same machine)?
Weirdly, once it attempts to open with forward slash .../libssl.a, once with backslash ...\libssl.a - but at least the first path checks out in a bash shell, as shown above?
It gets even worse if I try to specify -l:libssl.a -- or if I specify -L/z/path/to/libs/openssl/lib/mingw -Wl,-Bstatic -lssl -- instead; then all attempts to open are with a backslash:
...
attempt to open /z/path/to/scripts/other/build/openssl/build/mingw/lib\libssl.a failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
To top it all off, if I look it up manually through the command line using ld, it is found ?!:
$ ld -L/z/path/to/libs/openssl/lib/mingw -lssl --verbose
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/ssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
Does anyone have an idea why this happens, and how can I get ld to finally find these libraries? Or rather - how can I troubleshoot, and understand why these libraries are not found, when they exist at the paths where ld tries to open them?
OK, found something more - not sure if this is a bug; but my problem is that I'm actually reading arguments from a file (otherwise I get g++: Argument list too long). So, to simulate that:
$ echo " -Wl,--verbose -L/z/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
# nothing
$ g++ `cat tcmd3` 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
... it turns out, if the very same arguments are fed on the command line, then static library lookup succeeds - but if the arguments are read from file through the # at-sign, then static library lookup fails?! Unfortunately, I cannot use on my actual project, since even with cat, I'd still get g++: Argument list too long ... So how can I fix this?
MSYS has special handling of directories as arguments when they are used in the shell. This translates e.g. /<drive_letter>/blabla to the proper Windows style paths. This is to accomodate Unix programs that don't handle Z: style directory root.
What you see here is that MSYS isn't performing this interpretation for string read from a file. When you think about it, it's very logical, but as you have experienced first-hand, also sometimes annoying.
Long story short: don't put Unix style paths in files with command arguments. Instead, pass them through e.g. cygpath -w, which works in MSYS2 (which should be the MSYS that Git for Windows 2+ comes with).
Ok, with some more experiments, I noticed that:
-L/z/path/to/libs/openssl/lib/mingw, the Unix path specification, tends to fail - while if we specify the same, except starting with a Windows drive letter, that is:
-LZ:/path/to/libs/openssl/lib/mingw, then things work - also from an arguments file with # at-sign:
$ echo " -Wl,--verbose -LZ:/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
I guess, since the shell is MSYS2/git-bash.exe, entering full POSIX paths on the shell with /z/... is not a problem, because the shell will convert them - but in a file, there is nothing to convert them, so we must use Windows/MingW convention to specify them...
I have a Rails application running on a CentOS 7 machine. I would like to read the system-configured region (Olson time zone) into a string (e.g. 'Europe/Stockholm', 'US/Eastern', etc).
I'm not interested in results that differ depending on whether daylight saving is active - 'CET' and 'CEST' and stuff like that won't do it for me. I've dug around Time and TZInfo but can't seem to find anything fitting.
Any ideas?
EDIT: It turns out Rails has no native way of getting the Olson time zone - one would have to do it in the shell, something like this. Neikos' suggestion below is shorter but doesn't work for me because my machine is a modified version of CentOS 7 which is stripped of timedatectl but is perhaps useful for someone else.
EDIT 2: I ended up calling the following shell script from within ruby:
#!/bin/bash
checksum=`md5sum /etc/localtime | cut -d ' ' -f1`
find /usr/share/zoneinfo/ -type f | xargs md5sum 2> /dev/null |
grep "^$checksum" | sed "s,.*/usr/share/zoneinfo/,," |
sort -n | head -n1
Since you are on CentOS 7 you could use something akin to timedatectl | grep Time zone and parse the timezone out of that.
This is obviously not portable to non-systemd systems.
As a not so pretty oneliner:
`timedatectl | grep "Time zone"`.split(/:|\(/)[1].strip
I want to basically implement an alias (using cd) which takes me to the 5th directory in my pwd. i.e.
If my pwd is /hm/foo/bar/dir1/dir2/dir3/dir4/dir5, I want my alias, say cdf to take me to /hm/foo/bar/dir1/dir2 .
So basically I am trying to figure how I strip a given path to a given number of levels of directories in tcsh.
Any pointers?
Edit:
Okay, I came this far to print out the dir I want to cd into using awk:
alias cdf 'echo `pwd` | awk -F '\''/'\'' '\''BEGIN{OFS="/";} {print $1,$2,$3,$4,$5,$6,$7;}'\'''
I am finding it difficult to do a cd over this as it already turned into a mess of escaped characters.
This should do the trick:
alias cdf source ~/.tcsh/cdf.tcsh
And in ~/.tcsh/cdf.tcsh:
cd "`pwd | cut -d/ -f1-6`"
We use the pwd tool to get the current path, and pipe that to cut, where we split by the delimiter / (-d/) and show the first 5 fields (-f1-6).
You can see cut as a very light awk; in many cases it's enough, and hugely simplifies things.
The problem with your alias is tcsh's quircky quoting rules. I'm not even going to try and fix that. We use source to evade all of that;
tcsh lacks functions, but you can sort of emulate them with this. Never said it was pretty.
#carpetsmoker's solution using cut is nice and simple. But since his solution awkwardly uses another file and source, here's a demonstration of how to avoid that. Using single quotes prevents the premature evaluation.
% alias cdf 'cd "`pwd | cut -d/ -f1-6`"'
% alias cdf
cd "`pwd | cut -d/ -f1-6`"
Here's a simple demonstration of how single quotes can work with backticks:
% alias pwd2 'echo `pwd`'
% alias pwd2
echo `pwd`
% pwd2
/home/shx2
I have the following file:
asdasd
asd
asd
incompatible:svcnotallowed:svc\:/network/bmb/clerver\:default
incompatible:svcnotallowed:svc\:/network1/bmb/clerver\:default
incompatible:svcnotallowed:svc\:/network2/bmb/clerver\:default
asdasd
asd
asd
as
And now suppose I have the two variables v1="incompatible:svcnotallowed:" and v2="svc\:/network1/bmb/clerver\:default".
I would like to search the entire file using v1 and v2. I know this is a problem caused due to the file having a'\' in it. I just dont know how to eliminate it. I have tried storing v1 and v2 (both variable contents and grep usage) using single quotes, but in vain.
This is the series of commands I have tried :
grep "$v1$v2" file
grep '$v1$v2' file
I need this to work in KSH
please let me know the right way to use grep in this scenario.
Thanks.
grep -F "$v1$v2" file should do the trick -- with the -F option, it treats the pattern as a fixed string, so backslashes don't get interpreted as escapes or backreferences.
But fgrep "$v1$v2" file would probably be the most portable solution. As tomkaith13 notes in his comment, the -F option to grep isn't universally supported. On Solaris, the default grep doesn't support -F, but the version in /usr/xpg4/bin does.
Since you are using ksh, you can just use it to read the files
v1="incompatible:svcnotallowed:"
v2="svc\:/network1/bmb/clerver\:default"
while read -r line
do
case "$line" in
"$v1$v2" ) echo "$line";;
esac
done < file