Earlier quoted context omitted.
Illumos is also a supported platform (SPARC and x86-64).
You obviously haven't tried it on either of those. They are "second tier", which means one is completely on one's own. What in your opinion would have to be the size of the source code to warrant jumping through the hoops to get this software running, as opposed to a combination of find + xargs + egrep,fgrep,awk?
Don’t underestimate grep-based code scanning
61–70 of 122 posts
Re: Don’t underestimate grep-based code scanning
#62One thing which was not immediately obvious to me for a while: the stricter your language’s formatting is, the easier it will be to grep source code. I work a lot with Go, where all code in our repository is gofmt'ed. You can get quite far with regular expressions for finding/analyzing Go code. (And when regexps don’t cut it anymore, Go has excellent infrastructure for working with it programmatically. http://golang.…
Related to this, it is generally a very good idea to be strict when naming functions, parameters, variables, etc. so that each concept has exactly one name throughout the codebase.
I've seen function names misspelled, and then every invocation just doubling down on that misspelling.
Re: Don’t underestimate grep-based code scanning
#63Still never going to beat AST-integrated searching like VS has for C#. Which has a regex search too.
Are there any stand-alone AST based search tools?
Re: Don’t underestimate grep-based code scanning
#64This is were you could be wrong. We would need to give a reason for dismissing it and then the risk officer would need to approve it (or reject it). False positives can be a real pain in the ass.
Re: Don’t underestimate grep-based code scanning
#65Earlier quoted context omitted.
And that’s why PowerShell is awesome :)
Powershell falls over in the other direction: the objects flowing down the pipeline are "magic" and can't be serialised, or even necessarily inspected with normal tools. For most unix operations you can replace foo | sort with foo > file sort I like the idea of powershell, but every time I try to do something complicated with it I'm disappointed.
$WhateverObject | Export-CliXml
$WhateverObject = Import-CliXml whatever.xml
Most of the time `>` also work.By the way, PowerShell serialization is by orders of magnitude better then anything *nix has to offer as you can use objects from other machine shell just like they exist on your local one.
> I like the idea of powershell, but every time I try to do something complicated with it I'm disappointed.
I did some very complicated things in PowerShell. For example, check out the script that maintains ~300 mainstream packages on Chocolatey up to date, all in few minutes with bunch of self maintenance features.
You need to learn it, simple as that.
https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7...
Re: Don’t underestimate grep-based code scanning
#66Earlier quoted context omitted.
Powershell falls over in the other direction: the objects flowing down the pipeline are "magic" and can't be serialised, or even necessarily inspected with normal tools. For most unix operations you can replace foo | sort with foo > file sort I like the idea of powershell, but every time I try to do something complicated with it I'm disappointed.
That is some serious BS. Objects can be serialized easily. $WhateverObject | Export-CliXml $WhateverObject = Import-CliXml whatever.xml Most of the time `>` also work. By the way, PowerShell serialization is by orders of magnitude better then anything *nix has to offer as you can use objects from other machine shell just like they exist on your local one. > I like the idea of powershell, but every time I try to do so…
Re: Don’t underestimate grep-based code scanning
#67Earlier quoted context omitted.
You obviously haven't tried it on either of those. They are "second tier", which means one is completely on one's own. What in your opinion would have to be the size of the source code to warrant jumping through the hoops to get this software running, as opposed to a combination of find + xargs + egrep,fgrep,awk?
> one is completely on one's own That's not accurate. The test suites are not run on CI for tier 2, but they are at least guaranteed to build. Tier 2 platforms have binary builds, are supported by rustup and often work just fine.
You need rust to build Firefox, so any platform that can't get it to work well is going to be at a disadvantage.
Re: Don’t underestimate grep-based code scanning
#68Don't use grep. Use ag[0], which is specifically designed for searching code. It's much faster, honors .gitignore, and the output can be piped back through grep if you like. ag FooBar | grep -v Baz It's in brew/apt/yum etc as `the_silver_searcher` (although brew install ag works fine too). 0: https://github.com/ggreer/the_silver_searcher
Re: Don’t underestimate grep-based code scanning
#69Don't use grep. Use ag[0], which is specifically designed for searching code. It's much faster, honors .gitignore, and the output can be piped back through grep if you like. ag FooBar | grep -v Baz It's in brew/apt/yum etc as `the_silver_searcher` (although brew install ag works fine too). 0: https://github.com/ggreer/the_silver_searcher
Re: Don’t underestimate grep-based code scanning
#70Earlier quoted context omitted.
Related to this, it is generally a very good idea to be strict when naming functions, parameters, variables, etc. so that each concept has exactly one name throughout the codebase.
Also, check your spelling. It's a pain when items don't show up in search because of spelling issues. I've seen function names misspelled, and then every invocation just doubling down on that misspelling.