I had some iOS projects in my macbook,one day I copied them to my pc which is based on windows system, then some day I copied them back to my macbook and I found the projects can not run.
I Opened one of the projects with Xcode, it says "builde successfully",but the app can not be deployed on the iPhone Simulator even if the Simulator is running!?!?!?! Then I check the files using "ls -l" command and found that the difference between normal Xcode project files and the new created Xcode project files is just a symbol.
files with problem:
drwx------+ 49 dingvimer staff 1.6K
normal file：
drwx------# 60 dingvimer staff 2.0K
How can I change that '+' symbol to '#' and get the project run normally?
I will appreciate your kindness of helping me to figure it out (^-^).
You can use ls -l# to see extended attributes. It will show you something like:
drwxr-xr-x# 5 cody staff 170 Mar 30 08:46 test.xcodeproj
LastUpgradeCheck 4
LastUpgradeCheck - is the name of attribute (sometimes there can be something like com.apple.blablabla) and 4 - is the value.
Use xattr command to set/delete extended attributes. See man xattr (its quite short and there are some examples).
Note, that you'll probably need to fix whole project directory.
Related
I'm not a front-end developer, but I need to get a sonarqube scan working with unit test coverage. All of this WAS working, but we had a big SonarQube version upgrade (6.x to 7.9.1), and it was broken for a while, and now I'm trying to get it working again.
As this used to work, what we have must be close, but there's some detail that isn't quite right.
When the build runs, it runs the unit tests and appears to generate coverage data, and the call to "sonar-scanner" sends the path to the lcov.info file. In the SonarQube project, it has a large number of "lines to cover", but with the same number of uncovered lines. I also note that it doesn't have a "Unit Tests" section in the overview.
In the build output, I see quite a few lines like this:
DEBUG: 'src/api/Api.spec.tsx' indexed as test with language 'ts'
But as noted above, the SonarQube project doesn't appear to think there are any unit tests.
As part of the build script, at the end of the tests run, I ran "ls -lt coverage" to see what was generated, and it showed this:
total 6264
-rw-r--r-- 1 81050 20059 1229978 Jan 4 19:12 clover.xml
-rw-r--r-- 1 81050 20059 720443 Jan 4 19:12 lcov.info
drwxr-xr-x 6 81050 20059 4096 Jan 4 19:12 lcov-report
-rw-r--r-- 1 81050 20059 4455341 Jan 4 19:12 coverage-final.json
I see references in this file to "Api.tsx" (and many others), but I don't see a reference to "Api.spec.tsx", but I have no idea whether I should expect any.
I've looked at the jest configuration in "package.json", but I don't see any obvious problems.
What else can I show here that might provide a clue?
Update:
Here is the resulting sonar-scanner command line, with some elisions:
sonar-scanner -Dsonar.typescript.node=/opt/app/bin/node -Dsonar.nodejs.executable=/opt/app/bin/node -Dsonar.host.url=http://... -Dsonar.login=... -Dsonar.password= -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info -Dsonar.typescript.lcov.reportPaths=coverage/lcov.info -Dsonar.branch.name= -Dsonar.language=js -Dsonar.projectKey=... -Dsonar.projectName=... '-Dsonar.exclusions=**/*.scss.d.ts, **/*.scss, **/*Props.ts, **/*State.ts, **/*index.ts' '-Dsonar.coverage.exclusions=**/*.spec.tsx, **/*.spec.ts, **/*.scss.d.ts, **/*.css.d.ts, **/*.scss' -Dsonar.projectVersion=1.0.0 '-Dsonar.sources=src/components/,src/api/,src/models/mappers/, src/utils/' '-Dsonar.lang.patterns.js=*/.ts,*/.tsx' -Dsonar.js.file.suffixes=.ts,.tsx -Dsonar.sourceEncoding=UTF-8 -Dsonar.tests=src '-Dsonar.test.inclusions=**/*.spec.tsx' -Dsonar.typescript.tslintconfigpath=tslint.json -Dsonar.log.level=DEBUG -Dsonar.verbose=true '-Dsonar.exec.maxBuffer=1024 * 1024'
I'd forgotten I'd asked this question. I had to go back to the code and history to see if I could remember what I did to fix it. I assume it would be what I discovered here:
https://community.sonarsource.com/t/sensor-sonarts-coverage-fails-to-match-path-with-symbolic-link/14601
In short, if file paths in the generated files include symbolic link entries, there was a bug in SonarTS that made it fail to follow symbolic links. What I did to fix this particular problem was examine my generated files to understand the pattern of what symbolic links were being utilized, and I wrote a script to post-process the lcov.info and test-report.xml file to replace paths to symbolic links with the absolute path to the non-symlinked file.
I have been following this guide from the gentto wiki to install Gentoo. I have hit a bit of a roadblock though which looks reasonably simple but I am having trouble figuring it out.
On this page: https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot#test_secure_boot
In the Testing Secure Boot with a Signed Kernel section whilst executing the buildkernel command I get the following error:
* Updating old config using make olddefconfig
make: *** No rule to make target 'olddefconfig'. Stop.
* buildkernel: Error: Caught signal - exiting
I don't seem to have an olddefconfig at all and even if I did have one I am not entirely sure what rule should be added to the make file.
I have read the man page for the buildkernel command and gone over this description here but sadly I have still not managed to fix the issue.
Does anyone know how to rectify this error?
So I now have an answer for this. It sometimes happens when the kernel sources have been updated to a new version, but the symbolic link /usr/src/linux hasn't been updated to
match. Gentoo leaves a partially populated kernel source tree in
/usr/src/linux--genoo even when an old kernel source version is
unmerged, and if the symbolic link /usr/src/linux still points to this.
if you run:
eselect kernel list
and it produces something like:
Available kernel symlink targets:
[1] linux-4.14.63-gentoo-r1
and
ls -l /usr/src/
produces something along the lines of:
total 8
lrwxrwxrwx 1 root root 20 Aug 18 00:33 linux -> linux-4.14.61-gentoo
drwxr-xr-x 23 root root 4096 Aug 18 02:38 linux-4.14.61-gentoo
drwxr-xr-x 25 root root 4096 Aug 18 02:33 linux-4.14.63-gentoo-r1
Running the following command will update the symbolic link and let you get on with things.
eselect kernel set 1
I emailed the author of the guide to get this information so credit goes to her. I am leaving this here in case anyone else runs into this problem in future.
I (and my colleague) are having this problem with 32-bit applications on a 64-bit Windows 7 OS. We have also found the same problems when we invoke a 64-bit application and pass a path as described below as a parameter in cmd.exe.
Given the path "C:\dir1\dir2\file1.txt", we have some 32-bit applications that don't appear to be able to consistently resolve that path and find the file if there is a hidden file of a particular naming structure causing it to lose it's way.
For example, given the directory/file structure:
\dir1
\dir2
\file1.txt
\.dir2Blah
Of importance is that the "hidden" file's name starts with the same characters as those which indicate a directory at that same level of the hierarchy. What comes after that in the hidden file's name is irrelevant. It could be called ".dir2Whatever".
The problem is that more often than not (but not consistently always) some 32-bit applications we use can't find the file1.txt file. We're told it can't be found or it doesn't exist, etc. in the application. Using Process Monitor, we found the reason appears to be that while the path being asked for is C:\dir1\dir2\file1.txt, the path being evaluated by the the Windows system is C:\dir1\.dir2Blah\file1.txt.
We have found that some 32-bit applications appear to be able to work fine with those (what I would call) erroneous paths and successfully find the files in question but others do not.
As I said above, we have also found we can reproduce the problem with 64-bit applications if we try to open the file through a cmd.exe prompt; for example, "textpad.exe \dir1\dir2\file1.txt".
We've "googled" this problem for 2 days because we're completely stumped and cannot believe that no one else has ever encountered this if it's so "easy" to reproduce. My colleague and I are both able to cause the failure; not consistently, but file access will fail more than half the time when we set up the structure I described.
I've included a picture of Process Monitor showing this failure in two applications but succeeding in a third...here.
Can anyone tell me what is going on? First, why is it changing the path to use that hidden file rather than the directory name provided? And, more importantly, how can we make it stop ;-)?
Cheers,
jtm
Added later:
Here's the "dir /x" output for a directory where I'm having this problem.
24/05/2017 12:17 PM <DIR> .
24/05/2017 12:17 PM <DIR> ..
24/05/2017 12:17 PM 12 BLAHTS~1 .blahtst
23/05/2017 03:06 PM 104 JSHINT~1 .jshintrc
24/05/2017 12:16 PM <DIR> blah
24/05/2017 12:16 PM 0 blank.txt
24/05/2017 12:15 PM 6,624 INDEX~1.HTM index.html
24/05/2017 10:48 AM <DIR> js
It also indicates how we stumbled on the problem. I have an html file that is trying to load a JavaScript file under the /js directory, but there is also a .jshintrc file at the same level and my old Apache server can't find the files to serve them. If I remove the .jshintrc file, I can get around this, but this project isn't one I created and I'm leery of just removing things willy nilly.
I went downloaded the Apktools from the website and got 2 files: Apktool.txt and Apktool_2.2.2. I renamed the Apktool_2.2.2 to Apktools.jar per the instructions. I then went to terminal and this was what I did:
Last login: Fri Mar 17 12:08:55 on ttys000
Roberts-MBP:~ Robert$ cd documents
Roberts-MBP:documents Robert$ cd metronomeapp/apktool
Roberts-MBP:apktool Robert$ **java -jar apktool.jar**
Apktool v2.2.2 - a tool for reengineering Android apk files
with smali v2.1.3 and baksmali v2.1.3
Copyright 2014 Ryszard Wiśniewski <brut.alll#gmail.com>
Updated by Connor Tumbleson <connor.tumbleson#gmail.com>
usage: apktool
-advance,--advanced prints advance information.
-version,--version prints the version then exits
usage: apktool if|install-framework [options] <framework.apk>
-p,--frame-path <dir> Stores framework files into <dir>.
-t,--tag <tag> Tag frameworks using <tag>.
usage: apktool d[ecode] [options] <file_apk>
-f,--force Force delete destination directory.
-o,--output <dir> The name of folder that gets written. Default is apk.out
-p,--frame-path <dir> Uses framework files located in <dir>.
-r,--no-res Do not decode resources.
-s,--no-src Do not decode sources.
-t,--frame-tag <tag> Uses framework files tagged by <tag>.
usage: apktool b[uild] [options] <app_path>
-f,--force-all Skip changes detection and build all files.
-o,--output <dir> The name of apk that gets written. Default is dist/name.apk
-p,--frame-path <dir> Uses framework files located in <dir>.
For additional info, see: http://ibotpeaches.github.io/Apktool/
For smali/baksmali info, see: https://github.com/JesusFreke/smali
Roberts-MBP:apktool Robert$ **./apktool d metronome.apk**
-bash: ./apktool: No such file or directory
Roberts-MBP:apktool Robert$ **apktool d metronome.apk**
-bash: apktool: command not found
Roberts-MBP:apktool Robert$
You can see in the bold what I entered. On the 2nd and 3rd bold statements, I did it both ways because I found info that one of them works on windows and one on mac and since the mac one didn't work I wanted to try the windows one to see what it would say. Both the files are in the same directory with the apk file (metronome.apk) Does anyone know why this isn't working and what I can do to resolve it?
Thanks.
Robert
Try java -jar apktool.jar d metronome.apk
To elaborate, apktool.jar is not a command itself. It's a java Jar file that can be executed by the Java runtime.
I have recently upgraded my Ubuntu from 14.04 to 16.04 and started getting the following error when running any mvn commands (version 3.3.9): Error: Could not find or load main class .usr.share.maven.boot.plexus-classworlds-2.x.jar. My environment variables are declared as follows:
$JAVA_HOME: /usr/lib/jvm/java-8-oracle
$PATH: /usr/local/texlive/2015/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
$M2_HOME: /usr/share/maven
$M2: /usr/share/maven/bin
When trying to find a solution, I've tried removing the M2 and M2_HOME variables as suggested on various threads, which resulted in getting a different error: Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher. I have also tried running apt-get remove --purge maven and installing it again as well as downloading the .tar.gz archive, but in both cases, nothing has changed.
When looking into the /usr/share/maven/boot folder, there is a chain of symlinks pointing from plexus-classworlds-2.x.jar -> /usr/share/java/plexus-classworlds2-2.5.2.jar. Am I missing some dependencies? Or are there any old configuration files that did not get removed by --purge?
EDIT: When I execute mvn as root, I get the Launcher error instead of plexus-classworlds-2.x. Also, I have completely removed and reinstalled all plexus libraries, yet with no change.
Check if /usr/share/maven/boot has multiple jars with pattern /usr/share/maven/boot/plexus-classworlds-*.jar.
Mine was something like:
drwxr-xr-x 2 root root 4096 Dec 23 14:21 ./
drwxr-xr-x 6 root root 4096 Nov 14 2015 ../
-rw-r--r-- 1 root root 52684 Dec 12 2015 plexus-classworlds-2.5.2.jar
lrwxrwxrwx 1 root root 34 Dec 10 2015 plexus-classworlds-2.x.jar -> ../../java/plexus-classworlds2.jar
This messes up /usr/share/maven/bin/mvn bash script and executes a wrong java command.
I had to remove the jar and leave only the symbolic link.