When we type $ in chrome console it returns a function. I am sure it's not jQuery's $.
If I want to use jQuery in console, What is the best way to trigger jQuery in chrome console as $.
$ is an alias for document.querySelector. In the same vein there is $$ which is an alias for document.querySelectorAll.
It is defined in the Command line (console) api.
Command Line API Reference
The Command Line API contains a collection of convenience functions for performing common tasks: selecting and inspecting DOM elements, displaying data in readable format, stopping and starting the profiler, and monitoring DOM events.
If you have $ defined on the page as a global (perhaps by using jQuery), you'll get that global, not the command-line built-in.
There are other handy functions defined there.
To run jQuery, without having it in the page source code, you may find Chrome extensions to be handy, or simply copy-paste the jQuery source code in the console.
Related
I have a system that automatically creates and saves documents as html. For further storage they ought to be pdfs though.
I want to avoid having to do it manually so my preferred solution would be a small executable that I can call via command line, feed it with a source and output path (and ideally further parameters) and then let it do its magic. Something in concept like this:
exampleConverter.exe "C:\source\document1.html" "C:\convertedPDFs\document1.pdf"
No UI whatsoever, no human input, no popping up and closing console.
I looked through several options, but common problems I encountered were
the software not being free for commercial use
It just being a library of code, not a ready-to-go executable / code-base you just need to compile into one
The tool needing to get installed instead of being 'portable'
I'd like to avoid having to implement any modern libraries myself, partially for simple time concearns, partially because internally our code runs in a less than modern IE & VBS context so I for see compatibility problems.
Simply triggering a precompiled executable through a generic command line inerface that I can trigger from vbs seems like the perfect solution here.
Your Windows OS program code is almost there, why not reverse input and output (makes the task easier later), with a switch or two. you can embellish that with your for /? loop to run through the current working folder, just like any other program.
Your pseudo code
exampleConverter.exe --print-to-pdf="C:\convertedPDFs\document1.pdf" --headless "C:\source\document1.html"
Working Windows native code
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --print-to-pdf="%CD%\out\document1.pdf" --headless "%CD%\in\document1.html"
Other options are available
learn.microsoft.com suggest this working snippet to run edge with parameters
wscript vbsEdge.vbs
Dim shell
Set shell = WScript.CreateObject("WScript.Shell")
shell.Run "msedge https://www.google.com --hide-scrollbars --content-shell-hide-toolbar"
So just combine the program methods. However, you need to sort out your own arguments.
For greater control then you need to step-up to heavier custom isations https://blogs.windows.com/msedgedev/2015/07/23/bringing-automated-testing-to-microsoft-edge-through-webdriver/ etc.
I am using jpegoptim in PhpStorm as external tool.
Works fine when I do select 1 file.
How can I apply that on many JPEG files ?
That's not possible at the moment (not supported).
https://youtrack.jetbrains.com/issue/IDEA-90239
https://youtrack.jetbrains.com/issue/IDEA-97869
Watch these tickets (star/vote/comment) to get notified on any progress.
If you definitely need it in one go (and not calling that External Tools entry once for each file)... then what you may try is:
Select desired files
Use Copy Paths from context menu
Call another External Tools entry that:
Uses $ClipboardContent$ macro
It's some shell/batch script that parses such parameter (splits into separate lines to get individual paths) and then calls actual program in cycle -- once for each file from the parsed parameter.
A bit too complicated as for my liking... Plus, I've not tried it myself so not sure how line ending symbols will be passed here (so it can be parsed in the script).
BTW -- you can assign custom shortcut to particular External Tools entry so you may call it for each file individually -- it will be faster with shortcut than doing the same with the mouse.
I have a C extension to Tcl where command mytest is defined. The extension is compiled correctly (I am on Linux, extension is *.so). For example, I can start tclsh and use it like this:
$ tclsh
% load /path/extension.so
% mytest abc
...
But, if I create a file myscript.tcl with the following content:
load /path/extension.so
mytest abc
then I get error:
$ tclsh myscript.tcl
invalid command name "mytest"
while executing
"mytest abc"
(file "myscript.tcl" line 2)
I am using bash on Ubuntu 14.04. Tcl 8.6.
EDIT 1: My question/problem is that I want to use tclsh with a script as an argument - this script should properly load extensions in such a way that mytest and other implemented functions are working without error.
EDIT 2: Uhh, If I use command "source myscript.tcl" inside tcl shell the result is the same. If I use absolute path for myscript.tcl the error is still the same --- "load" executes without warning but I am not sure about it because I get invalid command name "mytest". Maybe the problem is with scope, but it is working correctly when tclsh is used interactively.
If you are using the full path of the extension library in both cases, that part should work identically. It probably is doing though; if it couldn't load it, it would generate an error (which might or might not be helpful, as some of the ways that things fail give very little information; Tcl reports what it has got, but that's sometimes not enough, as it is dependent on the OS to tell it some things). Instead, the problem is probably elsewhere.
The main difference between interactive use and scripted use is that in interactive use, the unknown command will expand unknown command names to Tcl commands that the thing you typed is an unambiguous prefix of. This is convenient, but when converting to a script, you should always use the full command name. OK, not the full full command name — you mostly don't want or need the :: namespace on the front — but without abbreviation, so don't use lappe for lappend. (In interactive use, Tcl will also exec things as external programs without requiring you to type the exec explicitly; again, that's turned off in scripts as it is rather fragile.)
Could it be that this is what is going on? You can check by setting the global variable tcl_interactive to 0 before typing in your code (I recommend using cut-n-paste for that typing, so that you know exactly what is going in). If that fails, it's the interactive-mode helpfulness that is tripping you up. Check what commands you might have as an expansion for a prefix with info commands (after the load, of course):
info commands mytest*
If that just reports mytest, my theory is wrong. (Well, if it does that and the length of that string is 6; there could theoretically be extra invisible characters have been put on the command name, which would be legal Tcl but very nasty and DON'T DO THAT!)
Run tclsh command without any tcl file, the interpreter will go into interactive mode.
Can I simply disable this feature by modifying the tclsh source code ?
I can't imagine why you would want to bother doing this, given that supplying any script file will turn off interactive mode. The script you supply will have full access to the additional arguments passed in (a list in the global argv variable) and the standard IO channels (stdin, stdout and stderr). It can exit when it is done. Literally anything you want can be done at that point; you've just got to write a script to do it.
If you're including Tcl in your own program, the behaviour of tclsh is implemented in the C function Tcl_Main. If you never call that — instead just using Tcl_FindExecutable, Tcl_CreateInterp and Tcl_Eval/Tcl_EvalFile — then you never get any of that interactive behaviour. While theoretically you could modify the Tcl source itself to do what you want — it's all open source — why would you bother when you could just not call that code in the first place?
I have a script that takes in multiple parameters, and that I've documented with proper help comments (e.g. .SYNOPSIS, .DESCRIPTION, .PARAMETER). Several different users in my organization are going to use this powershell script, some who know powershell and will call it from powershell with specific parameter values, and some who don't know powershell and will simply right-click on the script file in Windows Explorer and choose Run with PowerShell (so the parameters will use their default values).
My conundrum is what is the best way to do this in powershell without a bunch of duplicate code. The way I see it, these are my options:
1 - Just write a DoStuff.ps1 script that provides default values for all parameters. This allows it to be ran directly from Windows Explorer, but feels clunky for the powershell users that want to use it as a function from their own scripts, since instead of writing:
Do-Stuff param1 param1
they will be doing:
.\DoStuff.ps1 param1 param2
2 - Within DoStuff.ps1, move the operations it performs into a DoStuff function, and after the function declaration call the DoStuff function with the parameters passed into the script. This would still allow the script to be ran from Windows Explorer, as well as developers to dot source the script into their own scripts so they can access the function. The downside is that when the developers dot source the script, the script is going to call the function with the default parameters (unless I allow them to provide an optional Switch parameter to the script that triggers the function to not be called). Even with this though, it means that I would have to duplicate all of the scripts help text so that it shows for both the script and the function (description, parameter descriptions, etc.).
I can't think of any other options. Ideally I would just be able to write functions in .ps1 file and tag a function with a "default" keyword so that if the script is called, that function is ran by default; but I don't think PowerShell provides anything like this.
What do you think is the best approach in this situation. Is there something I'm overlooking or don't know about? Thanks.
but feels clunky for the powershell users that want to use it as a function from their own scripts
Default parameters would seem, based on your description, to be the best (or, at least, least-worse) approach.
But rather than naming your script DoStuff.ps1 name it and call it so it can be called more like an internal function:
Name it with the dash: Do-Stuff.ps1
Remember you don't need to specify the ps1
If the script is in a folder in $env:Path then you don't need to specify a path.
Also consider a script can load a module from a relative path: you could put most of the code in a script module which the front end (right click on it) script loads and calls into it. Script authors load the module themselves.