I'm using fastlane and I find that the default output of the command is quite verbose.
This is the default output for one of my lanes, 46 lines of text.
https://pastebin.com/f30V071X
I found a way to reduce this output setting 3 special env variables
ENV["SNAPSHOT_SKIP_OPEN_SUMMARY"] = "1"
ENV["FASTLANE_SKIP_UPDATE_CHECK"] = "1"
ENV["FASTLANE_HIDE_TIMESTAMP"] = "1"
This is the minimum output I can have: https://pastebin.com/uUBvbj6V
Is there any way to disable everything accessory and only keep the output coming from the lane itself?
Related
I just notices that the command line tool, called like this: "ruamel.yaml.cmd rt --save $YAML_FILE", will break lists that either contain long strings, or hashes:
Example list containing a hash:
Source:
telegraf::inputs:
cpu:
- percpu: true
totalcpu: true
report_active: true
output:
telegraf::inputs:
cpu:
- percpu: true
totalcpu: true
report_active: true
example list containing long string:
source:
rsyslog::config::snippets:
00_forward:
ensure: 'present'
lines:
- 'if $syslogfacility != 1 then {'
- 'action(Name="collector-syslog" Type="omfwd" Target="%{hiera("rsyslog_server")}" Port="514" Action.ResumeInterval="5" Protocol="tcp")'
- '}'
output:
rsyslog::config::snippets:
00_forward:
ensure: present
lines:
- if $syslogfacility != 1 then {
- action(Name="collector-syslog" Type="omfwd" Target="%{hiera("rsyslog_server")}"
Port="514" Action.ResumeInterval="5" Protocol="tcp")
- '}'
I already created a bug report for this, but it was deleted with a comment pointing to https://yaml.readthedocs.io/en/latest/example.html?highlight=indent#output-of-dump-as-a-string.
But I am not sure how this code snipped should help me with the command line tool.
Or is the tool deprecated, and I have to roll my own?
The automatic detection of the indent seems incorrect for your input, as that input is inconsistent (your mappings are indented 2 positions and your sequences 4 positions with an offset for the block sequence indicator of 2). ruamel.yaml.cmd as on PyPI doesn't support different indentation levels for sequences and mappings (ruamel.yaml didn't when that was written, it does now).
Apart from that you cannot set the line width for the output in ruamel.yaml.cmd for older versions ( before 2020-12-01), and those versions are using the default 80 characters for the wrapping.
I recommend you upgrade to 0.5.6 and use the command line options:
yaml rt --indent 2 --width 1024 --save <yourfile>
The appropriate repository for ruamel.yaml.cmd is https://sourceforge.net/p/ruamel-yaml-cmd/code/ci/default/tree/ . A bug report on ruamel.yaml which can only be used from a Python program, should include the minimal source code of the program that reproduces the error, and if not provided, issues will be removed as announced on its create issue page.
I am completely new to this type of coding/command lines, so I am sorry if I am asking this question in a wrong way.
I want to loop over all files in a directory (I am quality trimming DNA sequencing files (.fastq format))
I have written this loop:
for i in *.fastq; do
perl /apps/prinseqlite/0.20.4/prinseq-lite.pl -fastq $i -min_len 220 -max_len 240 -min_qual_mean 30 -ns_max_n 5 -trim_tail_right 15 -trim_tail_left 15 -out_good /proj/forhot/qfiltered/looptest/$i_filtered.fastq -out_bad null; done
The code itself seems to work, I can see in my terminal that it is taking the right files and it is doing the trimming (it is writing a summary log in the terminal as it goes), but no output files are generated - i.e these ones:
-out_good /proj/forhot/qfiltered/looptest/$i_filtered.fastq
If I run the code in a non-loop way, just on one file it works (= the output is generated). link this example:
prinseq-lite.pl -fastq 60782_merged_rRNA.fastq -min_len 220 -max_len 240 -min_qual_mean 30 -ns_max_n 5 -trim_tail_right 15 -trim_tail_left 15 -out_good 60782_merged_rRNA_filt_codeTEST.fastq -out_bad null
Is there a simple reason/answer to this?
This problem has nothing to do with Perl at all.
/proj/forhot/qfiltered/looptest/$i_filtered.fastq is read by the shell as interpolating the contents of i_filtered. There is no such shell variable, so this argument turns into /proj/forhot/qfiltered/looptest/.fastq ($i_filtered turns into nothing).
Therefore all of your prinseq-lite.pl executions place their output in the same file, which (because its name starts with a .) is "hidden": You need to use ls -a to see it, not just ls.
Fix
... -out_good /proj/forhot/qfiltered/looptest/${i}_filtered.fastq
Note that this would give you e.g. 60782_merged_rRNA.fastq_filtered.fastq for an input file of 60782_merged_rRNA.fastq. If you want to get rid of the duplicate .fastq part, you need something like:
... -out_good /proj/forhot/qfiltered/looptest/"${i%.fastq}"_filtered.fastq
Trying to pass a large string to a shell script using a breakpoint in Xcode
let value = Array(repeating: "a", count: 1500).joined()
let string = "{\"key\": \"\(value)\"}"
Unfortunately, the string is being truncated. Is this limitation documented and can it be overcome?
It's been nearly a year since you asked this, and I'm not sure if it will solve your question, but I've recently had a similar problem so thought I'd share my solution.
I had two issues:
LLDB was truncating any arguments to my shell script (and string variables printed in the console using po foo) to 1023 characters. I believe this is the issue to which your question relates.
Xcode was incorrectly confusing a comma , in my string as a separator for multiple arguments (e.g. passing foo, bar, and baz as arguments to the script wouldn't work correctly if any of the variables contained a , as Xcode would try to create another argument).
So, firstly, the LLDB issue...
It seems that by default LLDB has a limit on the character length that it will print to the console (or pass to a shell script via a breakpoint argument) of around 1023 characters. You can easily change this to something larger by setting another breakpoint before the breakpoint that uses your variable and running (lldb) set set target.max-string-summary-length 10000 in the console. This can be a bit annoying so I created a ~/.lldbinit file and placed set set target.max-string-summary-length 10000 in there instead so I don't have to keep setting it in the console.
Secondly, the comma issue...
Inside the Edit breakpoint... menu that you provided a screenshot of above there is the option to not only provide a path to a script but to also provide arguments. I can see from your question that you provided the argument #string#. For my script, I was passing multiple arguments, which Xcode allows you to do using a comma separated list, e.g. #foo#, #bar#, #baz#. Each of these arguments was a string.
I noticed that sometimes one or more of these strings would truncate if they contained a comma: ,.
So the string:
{ "num_friends" : "7" }
would be passed to my script as expected. But the string:
{ "num_friends" : "7", "num_deleted_friends" : "1" }
would truncate and would be passed to my script as two separate arguments. It seems that Xcode would split any string with a , even when entered using #string#.
I validated this in my script by simply using something like:
for var in "$#"
do
echo "$var"
echo "===="
done
Where $# expands to contain each argument. From this I could see that #string# was being correctly passed to my script but separated as multiple arguments wherever there was a ,. So if #string# contained a comma my script would print:
#"{ \"num_friends\" : \"7\"
====
\"num_deleted_friends\" : \"1\" }"
instead of what I expected which was:
#"{ \"num_friends\" : \"7\", \"num_deleted_friends\" : \"1\" }"
So it seems like it might be a bug in how Xcode passes strings inside # expressions in the breakpoint editor window.
My crude solution has been to just replace any commas with another character and then replace them back again inside my script. There's probably a better way to do this but I don't require it for my needs.
I'm trying to get the below part of the code done in a relatively condensed fashion (to plug in to a much bigger script). I don't have any problems sending multiple commands this way. However, there's something that's causing the multi-line command to eventually choke. Syntax for Cisco comnmands appear to be correct. I'm not sure if I'm running into some kind of character limit or if I need to escape specific characters in $showintstatusCommands, but nothing I tried seems to work.
This code:
$BGPInterface = "GigabitEthernet0/2"
$showintstatusCommands = "`nterminal length 0`nsho int $BGPInterface | include reliability|errors`nsho log | include $Date.*LINK-3-UPDOWN.*$BGPInterface`nexit"
($Response = $showintstatusCommands | C:\Windows\plink.exe -ssh -2 -l $Credential.GetNetworkCredential().username -pw $($Credential.GetNetworkCredential().password) $DeviceName -batch) 2>$null | out-null
produces the below when I reveal the contents of the variables. $ShowIntstatusCommands appears to be correct when it echoes locally. Notice, the end of the 3rd line is cut off (number 2 character is missing at the end). Also the subsequent line is some weird residual of the previous line, which starts with $nclude.
PS C:\Users\MKANET\Desktop\test> $Response
CISCO-ROUTER#
CISCO-ROUTER#terminal length 0
CISCO-ROUTER#sho int GigabitEthernet0/2 | include reliability|errors
reliability 255/255, txload 1/255, rxload 1/255
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 output errors, 0 collisions, 3 interface resets
CISCO-ROUTER#sho log | include Jul 17.*LINK-3-UPDOWN.*GigabitEthernet0/
$nclude Jul 17.*LINK-3-UPDOWN.*GigabitEthernet0/2
CISCO-ROUTER#
CISCO-ROUTER#exit
PS C:\Users\MKANET\Desktop\test> $showintstatusCommands
terminal length 0
sho int GigabitEthernet0/2 | include reliability|errors
sho log | include Jul 17.*LINK-3-UPDOWN.*GigabitEthernet0/2
exit
When you write to a variable in a non-global scope (like script or function scope), PowerShell will not modify any higher level scoped variables of the same name. IOW $Response = 'foo' will create a local copy of the $Response variable and assign 'foo' to it. If your intent is to modify the global variable $Response then change the line to $global:Response = ... What you see in $global:Response is residual, probably from previous tinkerings.
I finally verified that the same behavior was happening on all the remote devices if I typed in the command below manually. The line get's jumbled up if too many characters were used.
I changed:
sho log | include $Date.*LINK-3-UPDOWN.*$BGPInterface
to the below command (removing just a couple of characters); and, it worked fine. It looks like it was a Cisco IOS CLI limit.
sho log | include $Date.*LINK-3-UPDO.*$BGPInterface
I'm trying to do this in my Makefile:
VAL=
TARGET1:
VAL= ... #compute value of VAL
#run some command that uses the value of VAL
TARGET2:
$(MAKE) TARGET1
#run other command that uses the value of VAL
But it turns out that value of VAL is reset when TARGET! completes in TARGET2. Thus the computed value of VAL is not available when I try to run the other command in TARGET2. Is there any way to keep the value computed in TARGET1? Thanks.
You have a fundamental misconception. The variable VAL that is set in the TARGET1 recipe is not a make variable at all: it's a shell variable. You can tell because if you change the syntax of the assignment to be something else that is still a valid make variable assignment but is not a valid shell variable assignment, like:
TARGET1:
VAL := foo
it will give you a syntax error. Basically in make, any recipe line (lines after a target that begin with a TAB character) are not interpreted by make at all: they're passed to a shell that make invokes. Nothing that happens in that shell can have any effect on the value of make variables, etc. of course.
You don't give us much detail. You don't say whether the command uses the variable from the environment or via the command line. You don't say what version of make you're using. If it's GNU make, you have a number of options. The simplest one is to set the value always; if it requires shell syntax you can use the shell function:
VAL := $(shell #compute value of VAL)
TARGET1:
#run some command that uses $(VAL)
TARGET2:
#run another command that uses $(vAL)
Before we give you more possibilities we need to understand the requirements: if you HAVE to have the value set in TARGET1 we need to know why, before we can offer possible solutions.