I am using Shoestrap, a WordPress theme based on Roots that uses Bootstrap and less. I added the Bootswatch Yeti theme variables.less to assets/less/bootstrap as as a replacement of the existing one and also added bootswatch.less. Then I added bootswatch.less to bootstrap.less. To recompile I ran grunt. The grunt file content I have added here.
I ran into two issues though. One error I do not know how to fix and one major issue that is that grunt seems to keep on removing assets/css/main.min.css all the time and then tells me the file or directory is missing. Here are the errors I had with --force activated:
grunt --force
Running "clean:dist" (clean) task
Running "less:dist" (less) task
>> NameError: variable #gutter is undefined in assets/less/app.less on line 5, column 13:
>> 4 .gallery-row {
>> 5 padding: (#gutter / 2) 0;
>> 6 }
Warning: Error compiling assets/less/app.less Used --force, continuing.
Running "uglify:dist" (uglify) task
File "assets/js/scripts.min.js" created.
Running "version" task
Warning: ENOENT, no such file or directory 'assets/css/main.min.css' Used --force, continuing.
Done, but with warnings.
It was the Byte Order Mark (BOM) signature that was an issue as I linked to before in the question. But both TextWrangler and Dreamweaver did not remove it. I found one command that did help here: Using awk to remove the Byte-order mark And I ran
awk '{if(NR==1)sub(/^\xef\xbb\xbf/,"");print}' app.less > app.less
which worked like a charm! Only the theme still has not changed in styling. That is rather odd.
Update I
The awk command emptied my app.less. I ran another command found here as well: Using awk to remove the Byte-order mark and that command:
sed -i .bak '1 s/^\xef\xbb\xbf//' *.less
did work without removing all data from app.less, but then I got the same error again:
Reading assets/less/app.less...OK
>> NameError: variable #gutter is undefined in assets/less/app.less on line 5, column 13:
>> 4 .gallery-row {
>> 5 padding: (#gutter / 2) 0;
>> 6 }
Did see TextMate added attributes and removed those using xattr -d com.macromates.caret file.less, but that did not do the trick either.
Update II
Seems that the variable #gutter does not exist. There seems to be a variable #grid-gutter-width. Thanks to at Roots Discourse I was notified - http://discourse.roots.io/t/grunt-hits-a-snag-compiling-gutter-not-defined/940/3 . Making an adjustment does not help though as other variables pop-up as issues. Will see if I can get some feedback from the Shoestrap team.
There was a bug in the shoestrap, theme, I believe we managed to fix it with this commit: https://github.com/shoestrap/shoestrap/commit/ff75cf73cf778e4b80c5e11544c0a67717fbcc10
Please let me know if that works for you...
Related
I have a tarball src.tar.gz whose contents are unpacked into src/ and a patch of this sources generated with this command:
$ diff -Nurp src/ src_mod/ > my.patch
The patch header starts with this three lines:
diff -Nurp src/path/to/file src_PATCHED/path/to/file
--- src/path/to/file 2012-10-22 05:52:59.000000000 +0200
+++ src_PATCHED/path/to/file 2016-03-14 12:27:52.892802283 +0100
My bitbake recipe references both path and tarball files using this SRC_URI:
SRC_URI = " \
file://my.patch \
file://src.tar.gz \
"
do_fetch and do_unpack tasks work as expected, leaving my.patch and src/ inside ${S} directory, that is:
${S}/my.path
${S}/src.tar.gz
But do_patch task is failing with this ERROR message:
ERROR: Command Error: exit status: 1 Output:
Applying patch my.patch
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
I have tested different alternatives, for example setting "patchdir" attribute like showed below:
SRC_URI = " \
file://my.patch;patchdir=${S}/src \
file://src.tar.gz \
"
I expected "patchdir" being the same as using "patch -d dir". But it doesn't work as expected, it always returns the same ERROR message.
What I am doing wrong?
My variable ${S} was re-defined inside my recipe with this content:
S = "${WORKDIR}/${PN}-${PV}"
But the fetchers downloads my.patch and src/ inside ${WORKDIR}, not inside ${S} directory, so:
${WORKDIR}/my.path
${WORKDIR}/src.tar.gz
And tarball was also extracted inside ${WORKDIR}
${WORKDIR}/src/
The fix was setting "patchdir" attribute properly, replacing ${S} by ${WORKDIR}
SRC_URI = " \
file://my.patch;patchdir=${WORKDIR}/src \
file://src.tar.gz \
"
That is already working!
Though the author provided their own solution to their distinct problem, this question is the first result that comes up when searching for solutions to the "can't find file to patch" error in Yocto builds, so I want to share a solution for a different situation that produces the same error output.
In my case, I was trying to use a .bbappend file to apply an override controlled patch to a pre-existing recipe, and was receiving the "can't find file to patch" error. The thread at https://community.nxp.com/thread/474138 identified the solution: using the '_append' syntax instead of the '+=' syntax. That is, use:
SRC_URI_append_machineoverride = " file://my.patch"
Instead of
SRC_URI_machineoverride += "file://my.patch"
Note that the use of '_append' requires a leading space (contra the trailing space noted in the thread linked above). I have not yet investigated this enough to explain why this syntax is necessary, but I thought this would still be a valuable addition to the record for this question.
How would I hide the computer name in the prompt while using the terminal?
At the moment it shows both username and computer name like so:
It would save some space by removing anwarchoukah#anwars-mbp, seeing as I actually know who I am:)
Try to add export DEFAULT_USER=$USER to your .zshrc file
On MacOS 10.15 Catalina:
Open the file /private/etc/zshrc in a text editor
Locate the comment: # Default prompt
Modify the line that looks like this: PS1="%n#%m~ %& # "
Save the file. You will be prompted to enter a password to save it.
Load a new Terminal window.
For example, you can:
Remove "%n#%m" to get rid of both the username and computer name
Remove "%n" to get rid of the user name
Remove "%m" to get rid of the machine name
step 1. one your .zshrc file by vim .zshrc
step 2. go to end of your file.
Paste this code:
careful indent again your code
prompt_context() {
if [[ "$USER" != "$DEFAULT_USER" || -n "$SSH_CLIENT" ]]; then
prompt_segment black default "%(!.%{%F{yellow}%}.)$USER"
fi
}
EDIT - explaining what this does
This will remove the machine#user name from the prompt IF:
- you are not logged in as the default user
- you are not in an ssh client shell
For most people, not needed, but if you regularly ssh to other machines and have multiple terminals open (eg remote sys admin type work) then this is extremely useful so when you look at your terminal you know which machine and user you are logged in as inside that terminal.
If you don't need/manage that type of complexity then use one of the other answers to just modify your export PROMPT/PS1 value.
* WARNING *
If you are using a custom shell or theme, this might not work and although the prompt will no longer show your computer and username it will keep throwing the error:
prompt_context:2: command not found: prompt_segment
For example, you can see with this (very popular) powerlevel9k it does not work. This is because the Powerlevel9k theme uses it's own magic and you simply add commands to your ~/.zshrc file to get the same result, eg:
POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(context)
More info on that here.
Open up .zshrc, find the line reading export PS1 or maybe export PROMPT.
Remove the variable that is used for the hostname, could be %m or %M.
Zsh on Archlinux wiki
You can use colors and also have a prompt (or some information) on the right side.
I like this approach (on my mac)
put in .zshrc
PS1="%n$ "
The terminal will look like
username$
Just add prompt_context() {} to .zshrc
Unfortunately none of the .zshrc changes worked for me.
Machine : Mac M1, Big Sur 11.4
So this is what worked.
I Navigated to where the ZSH themes were installed, opened my theme, agnoster in TextEdit, and modified the configuration where it chooses what do display, which by default is $username#%m.
Note : %m here is the machine name.
Here is a screenshot of delta. Yellow is what I did, Green is the default setting from github version of agnoster theme.
Voila this worked. Now to me it just displays the machine name, as I intended.
Hope that helps. Many links and SOF posts only made me click that solution.
Set DEFAULT_USER in ~/.zshrc file to your regular username. You can get your exact username value by executing whoami in the terminal.
Something like this:
export DEFAULT_USER=username
If you are using PowerLevel9k theme, there is a variable POWERLEVEL9K_CONTEXT_TEMPLATE that can change the view of your hostname and computer name.
The default option is %n#%m,
%n -> username
%m -> machine name
to hide hostname:
Open the .zshrc file using sudo nano ~/.zshrc
Add the line
POWERLEVEL9K_CONTEXT_TEMPLATE="%n" at the end of .zshrc file
Save the file.
Maybe this will help you [ Open Profile => Shell ]
PS1="~ $: ";clear;
Just add this to your ~/.zshrc file:
export DEFAULT_USER=\`whoami`
Install Oh My Zsh is the easiest solution for me:
https://ohmyz.sh/
One liner install:
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
Result:
If you're using Powerlevel10k, then you can run p10k configure and configure the output a bit.
My username and computer-name was gone after having gone through it. It feel less hacky, than the other solutions here.
I don't know why I can't find a simplified solution.
So here is the simplified one.
Just jump into the themes directory,
# ~/.oh-my-zsh/themes
Select the theme, as I have been using
# vim agnoster.zsh-theme
Just remove %m to remove and also you can remove the username too.
Once done,
Just run
#zsh
To reflect the changes, Enjoy :)
Thanks to Wes Bos' amazing video series Command Line Power User , I managed to find the answer.. It's pretty simple. Stuff like that is set in the ZSH theme.
Open up .zshrc, change the theme from ZSH_THEME="agnoster" (which is what I was using) to something else.
Wes Bos has made a lovely theme called Cobalt2 which does exactly what I was looking for :)
I've now changed it to ZSH_THEME="cobalt2"
After watching Chris Coyer's
http://www.youtube.com/watch?v=M7W5unPM_b4&list=UUADyUOnhyEoQqrw_RrsGleA
I was wondering - is it possible to autorun Autoprefixer Sublime plugin right after the CSS file is built and without Grunt? What would I need to configure in Sublime and how?
Ideal chain would be:
Build compressed "style-unprefixed.css" on SASS save - run Autoprefixer - create compressed "style.css"
I'm no expert, but I think I just figured out how to do this, via a shell script.
Prerequisites:
SublimeOnSaveBuild (ST2 Plugin, also works on ST3)
SASS compiler (I'm using LibSass/SassC)
Autoprefixer (not the ST plugin)
After all that is taken care of, we'll create the script. For our purposes, let's call it buildcss.sh:
#!/bin/bash
if [ $# == 0 ]
then
echo "Usage: buildcss.sh [scss file] [css file]"
exit
fi
# Create the css file ($2) from a scss file ($1)
# see "sassc -h" for additional options
sassc $1 $2
# Run autoprefixer, overwrite input .css file
# see "autoprefixer -h" for additional options
autoprefixer -b "> 1%" $2
Of course if you're using Ruby SASS (sass) instead of sassc, the script should be adjusted.
Okay, at this step you should be able to run something like ./buildcss.sh style.scss style.css to test and make sure that part works. Then it's just a matter of making Sublime Text run that and pass the correct arguments.
For that, create a custom build system. Tools > Build System > New Build System... in ST3. There may be some differences between ST2 and ST3 here, but in ST3 my configuration looks like:
{
"shell_cmd": "/path/to/script/buildcss.sh $file ${file_path/scss/css/}/${file_base_name}.css",
"selector": "source.scss",
"line_regex": "Line ([0-9]+):",
}
As you may notice, I'm exclusively setting up for scss, but if you need sass you could set up another similar build system, exchanging "sass" for "scss" throughout. This build system also assumes that you keep your files in a /scss subfolder, and that css files should go in a /css subfolder at the same level.
And there you have it! Whenever you save a .scss file, SublimeOnSaveBuild will do it's magic and fire our custom build, which will in turn call the script which calls sassc and autoprefixer.
I just made the switch to Zsh, but I'm facing a weird problem with it: every time I hit the tab key, the prompt goes up a line, thus eating what was above.
In order to demonstrate the problem more clearly, I created a GIF:
I'm using a custom theme and Oh My Zsh. You can find the theme here: http://pastebin.com/12dZtZf3.
EDIT: The problem seems to reside in my theme, as using other themes solves the problem.
EDIT: The culprit seems to be in the function that prints the row of dashes and the date above the prompt:
_professional_prompt_header() {
echo -n "$bg[grey]"
for i in {0..$(( $(tput cols) / 2 - 6 ))}; do
echo -n "--"
done
# Uncommenting this line fixes the problem.
# Tried echo without -n and print, but no success.
echo -n " %*$reset_color"
}
This has also emerged as an issue with multiline prompts in the release of zsh 5.3. As of 2017-01-13, a patch has not been released. A discussion and explanation can be found in this prezto issue.
More discussion of the offending zsh issue itself can be found here.
Hopefully a fix will emerge from the zsh project. If not, some workarounds mentioned on that github repo are to make your PROMPT variable only a single line, outputting any other lines in the precmd function. This seems like a pain, however, so until it is fixed (or decided to be a "feature"), the easiest fix sounds like it is to roll back to zsh 5.2.
When running a CMake generated Makefile with multiple processes (make -jN), the output often gets messed up like this:
[ 8%] [ 8%] [ 9%] Building CXX object App/CMakeFiles/App.dir/src/File1.cpp.o
Building CXX object App/CMakeFiles/App.dir/src/File2.cpp.o
Building CXX object App/CMakeFiles/App.dir/src/File3.cpp.o
I'm not sure, but I think this behavior is also there for Makefiles not generated by CMake. I'd say it happens when multiple processes write to stdout at the same time.
I know I'm probably being pedantic, but is there any (simple) fix to this? ;)
If you're using GNU make, you can do it by redefining SHELL such that commands are wrapped by a trivial utility that ensures atomicity of information printed to standard output. Here's a more detailed description, including sample source for the wrapper utility.
I tried to get the CMake people to fix this, but apparently they don't want to. See http://www.cmake.org/Bug/view.php?id=7062.
The specific CMake bug related to interleaved make output using -jN with N>1 is CMake bug 0012991: "Parallel build output mess". It is still open in the "backlog" state waiting to be fixed.
This bug is actually annoying enough that it's a strong reason to switch to Ninja instead of make. Plus the fact that Ninja is faster than make. Ninja also uses an appropriate number of parallel jobs based on the number of CPU cores present. Also cool is how Ninja is, by default, very quiet: all progress happens on a single line in the terminal unless the build process emits messages or a build step fails. If a build step fails, Ninja prints the full command line that invoked it and displays the output. It's really nice since it makes any warning or error messages stand out. Although currently there is no colored terminal output: that would be a nice improvement but for me the advantages of Ninja over make are tremendous.
Looks like it is already fixed. Add a -Oline parameter to the command line:
make -j 8 -Oline
Version of make:
GNU Make 4.3
Built for x86_64-pc-msys
Sun's (now Oracle's) dmake available on Linux and Solaris takes care of that.
See here and there.
Here is a simple working example of using a wrapper for Make. I'm not sure if I'd encourage it's use, but it's an idea.
# Makefile
SHELL = /tmp/test/wrapper
test: test1 test2
test1:
$(eval export TARGET=$#)
env
test2:
$(eval export TARGET=$#)
env
and this:
#!/usr/bin/env bash
# wrapper
bash $# | sed -e "s/^/${TARGET} /"